Ejecute su propio servidor privado de CA y ACME usando step-ca

Con el lanzamiento de hoy ( v0.13.0), ahora puede usar ACME para obtener certificados de step-ca. ACME ( RFC8555 ) es el protocolo que utiliza Let’s Encrypt para automatizar la administración de certificados para sitios web. ACME simplifica radicalmente la implementación de TLS y HTTPS al permitirle obtener certificados automáticamente, sin interacción humana.

	paso clic
	certificados de pasos

La compatibilidad con ACME step-casignifica que puede ejecutar fácilmente su propio servidor ACME para emitir certificados para servicios internos e infraestructura en producción, desarrollo y otros entornos de preproducción.

Caddy usando ACME para conectarse a step-ca

¿Por qué ACME?

La compatibilidad con ACME step-casignifica que puede aprovechar los clientes y bibliotecas de ACME existentes para obtener certificados de su propia autoridad de certificación (CA). La mayor parte de esta publicación demuestra cómo se hace eso.

Hay muchas razones por las que podría querer ejecutar su propia CA, pero las dos que guiaron nuestra implementación de ACME son:

Uso de ACME en producción para emitir certificados para cargas de trabajo, proxies, colas, bases de datos, etc. para que pueda usar TLS mutuo para autenticación y cifrado.
Simulación de CA de Let’s Encrypt en desarrollo y preproducción en escenarios donde la conexión al servidor de prueba de Let’s Encrypt es problemática.

Ejecutar su propia CA es más flexible que usar una CA pública de PKI web. Significa que no necesita confiar en más de 100 terceros para la seguridad de sus sistemas internos. Puede emitir certificados con nombres de host internos , con la duración que desee, utilizando cualquier tipo de clave, y no tiene que preocuparse por las amenazas públicas de PKI web como los límites de velocidad , China o la NSA .

Aún así, temíamos que pudiéramos alterar las plumas con este anuncio, por lo que contactamos a Let’s Encrypt hace unas semanas para darles una vista previa. Resulta que no teníamos nada de qué preocuparnos. Respondieron con entusiasmo. ¡Terminamos convirtiéndonos en patrocinadores y ahora tenemos nuevos amigos!

¡Nosotros también estamos emocionados!

A un alto nivel, ACME es bastante simple. Un cliente ACME crea una cuenta con un servidor ACME y envía un pedido de certificado. El servidor responde con una serie de desafíos que debe completar el cliente para demostrar el control sobre los identificadores (nombres de dominio) en el certificado. Una vez que el cliente completa con éxito estos desafíos, envía una solicitud de firma de certificado (CSR) y el servidor emite un certificado.

La parte más interesante de todo esto es el desafío, donde el cliente demuestra el control sobre un identificador. No existe una forma estándar única de «probar el control» sobre un «identificador», por lo que la especificación central de ACME lo convierte en un punto de extensión. Dicho esto, solo hay dos tipos de desafíos ampliamente utilizados en la práctica. Ambos están diseñados para demostrar el control sobre un nombre de dominio y ambos cuentan con el respaldo de step-ca:

El desafío HTTP (técnicamente, http-01), en el que el servidor ACME desafía al cliente a alojar un número aleatorio en una URL aleatoria en el dominio en cuestión y verifica el control del cliente emitiendo una solicitud HTTP GET a esa URL.
El Desafío de DNS (técnicamente, dns-01), en el que el servidor ACME desafía al cliente a proporcionar un registro TXT de DNS aleatorio para el dominio en cuestión y verifica el control del cliente consultando DNS para ese registro TXT

Eso debería ser suficiente información para comprender lo que está sucediendo, configurar, depurar y operar clientes ACME. Ahora probemos ACME con step-cao Smallstep Certificate Manager.

Uso de ACME con Smallstep Certificate Manager

Únase a nuestro equipo de ingeniería de soluciones mientras le muestran cómo comenzar a usar ACME en menos de tres minutos con Smallstep Certificate Manager , todo directamente en la interfaz de usuario del producto. Puedes registrarte y empezar aquí .

Uso de ACME con`step-ca`

Supongamos que lo ha instaladostep-ca (p. ej., usando brew install step), lo tiene ejecutándose en https://ca.internaly ha iniciado su(s) sistema(s) cliente ACME (o al menos instaló su certificado raíz en ~/.step/certs/root_ca.crt).

Habilitación de ACME

Para habilitar ACME, simplemente agregue un aprovisionador ACME a su step-caconfiguración ejecutando:

step ca provisioner add acme --type ACME

Ahora reinicie step-capara recoger la nueva configuración.

🏌️‍eso es.

Configuración de clientes

Para configurar un cliente ACME para conectarse step-ca, necesita:

Dirija al cliente a la URL correcta del directorio ACME
Dígale al cliente que confíe en el certificado raíz de su CA

Una vez que se emiten los certificados, también deberá asegurarse de que se renueven antes de que caduquen.

Dirigir a los clientes a la URL correcta del directorio ACME

La mayoría de los clientes de ACME se conectan a la CA de Let’s Encrypt de forma predeterminada. Para conectarse step-ca, debe apuntar al cliente a la URL correcta del directorio ACME .

Una sola instancia de step-capuede tener varios proveedores de ACME, cada uno con su propia URL de directorio de ACME que se ve así:

https://{ca-host}/acme/{provisioner-name}/directory

Acabamos de agregar un aprovisionador ACME llamado «acme». Su URL del directorio ACME es:

https://ca.internal/acme/acme/directory

Indicar a los clientes que confíen en el certificado raíz de su CA

La comunicación entre un cliente ACME y un servidor siempre utiliza HTTPS . De forma predeterminada, el cliente validará el certificado HTTPS del servidor utilizando los certificados raíz públicos en el almacén de confianza predeterminado de su sistema . Eso está bien cuando se conecta a Let’s Encrypt: es una CA pública y su certificado raíz ya está en el almacén de confianza predeterminado de su sistema. Su certificado raíz interno no lo es, por lo que las conexiones HTTPS de los clientes ACME step-cafallarán.

Hay dos formas de abordar este problema:

Configure explícitamente su cliente ACME para que confíe step-caen el certificado raíz, o
Agregue step-cael certificado raíz al almacén de confianza predeterminado de su sistema (por ejemplo, usando step certificate install)

Si está utilizando su CA para TLS en producción, configurar explícitamente su cliente ACME para que solo confíe en su certificado raíz es una mejor opción. Demostraremos este método con varios clientes a continuación.

Si está simulando Let’s Encrypt en preproducción, instalar su certificado raíz es una simulación de producción más fiel. Una vez que se instala su certificado raíz, no es necesaria ninguna configuración de cliente adicional.

Ejemplos

step-cadebería funcionar con cualquier cliente compatible con ACMEv2 ( RFC8555 ) que admita el desafío http-01, dns-01o . tls-alpn-01Si tiene algún problema, inicie una discusión o abra un problema .

Veamos algunos ejemplos.

certbotes el abuelo de los clientes de ACME. Construido y respaldado por EFF , es el abanderado de ACME de línea de comandos de grado de producción.

Para obtener un certificado de step-causo certbotnecesita:

Apunte certbota la URL de su directorio ACME usando la --serverbandera
Dígale certbotque confíe en su certificado raíz usando la REQUESTS_CA_BUNDLEvariable de entorno

Por ejemplo:

$ sudo REQUESTS_CA_BUNDLE=$(step path)/certs/root_ca.crt \
  certbot certonly -n --standalone -d foo.internal \
    --server https://ca.internal/acme/acme/directory

sudose requiere en certbotel modo independiente de para que pueda escuchar en el puerto 80 para completar el http-01desafío. Si ya tiene un servidor web en ejecución, puede usar el modo webroot en su lugar. Con el complemento apropiado certbot también soporta el dns-01desafío para los proveedores de DNS más populares. Las integraciones más profundas con nginx y apache pueden incluso configurar su servidor para usar HTTPS automáticamente (lo configuraremos nosotros mismos más adelante). Todo esto funciona con step-ca.

Puede renovar todos los certificados que ha instalado usando cerbotejecutando:

$ sudo REQUESTS_CA_BUNDLE=$(step path)/certs/root_ca.crt certbot renew

Puede automatizar la renovación con una simple cronentrada:

*/15 * * * * root REQUESTS_CA_BUNDLE=$(step path)/certs/root_ca.crt certbot -q renew

Los certbotpaquetes para algunas distribuciones de Linux crearán una cronentrada o un temporizador systemd como este para usted. Esta entrada no funcionará step-caporque no establece la REQUESTS_CA_BUNDLEvariable de entorno . Tendrá que modificarlo manualmente para hacerlo.

Más sutilmente, certbotel trabajo de renovación predeterminado de Let’s Encrypt está ajustado para la vida útil de los certificados de 90 días de Let’s Encrypt: se ejecuta cada 12 horas, con renovaciones reales para los certificados dentro de los 30 días posteriores al vencimiento. De forma predeterminada, step-caemite certificados con una vida útil mucho más corta de 24 horas. La cronentrada anterior explica esto ejecutándose certbot renewcada 15 minutos. También querrá configurar su dominio para que solo renueve los certificados cuando estén a unas pocas horas de caducar agregando una línea como:

renew_before_expiry = 8 hours

en la parte superior de su configuración de renovación (por ejemplo, en /etc/letsencrypt/renewal/foo.internal.conf).

acme.sh es otro popular cliente ACME de línea de comandos. Está escrito completamente en shell ( bash, dashy shcompatible) con muy pocas dependencias.

Para obtener un certificado de step-causo acme.shnecesita:

Apunte acme.sha la URL de su directorio ACME usando la --serverbandera
Dígale acme.shque confíe en su certificado raíz usando la --ca-bundlebandera

Por ejemplo:

$ sudo acme.sh --issue --standalone -d foo.internal \
    --server https://ca.internal/acme/acme/directory \
    --ca-bundle $(step path)/certs/root_ca.crt \
    --fullchain-file foo.crt \
    --key-file foo.key

Me gusta certbot, acme.shpuede resolver el http-01desafío en modo independiente y en modo webroot . También puede resolver el dns-01desafío de muchos proveedores de DNS .

Las renovaciones son un poco más fáciles ya acme.shque recuerda usar el certificado raíz correcto. También puede recordar cuánto tiempo le gustaría esperar antes de renovar un certificado. Desafortunadamente, la duración se especifica en días (a través de la --daysbandera), lo cual es demasiado aproximado para step-cala vida útil predeterminada de 24 horas del certificado. Entonces, la forma más fácil de programar renovaciones acme.shes forzarlas con una frecuencia razonable, como cada 8 horas, a través de cron:

0 */8 * * * root "/home/<user>/.acme.sh"/acme.sh --cron --home "/home/<user>/.acme.sh" --force > /dev/null

stepes una utilidad de seguridad versátil que puede reemplazar opensslla mayoría de las tareas de administración de certificados. También es un step-cacliente. Con el lanzamiento de hoy ( v0.13.0), hemos agregado ACME a la lista de formas de step obtener certificados de step-ca. La compatibilidad con ACME también significa stepque puede obtener certificados de otras CA de ACME, como Let’s Encrypt’s.

	paso clic
	certificados de pasos

Obtener certificados de`step-ca`

Una vez que haya instaladostep y arrancado su entorno , puede obtener un certificado step-caejecutando el step ca certificatesubcomando y seleccionando su aprovisionador ACME de forma interactiva:

$ sudo step ca certificate foo.internal foo.crt foo.key
Use the arrow keys to navigate: ↓ ↑ → ←
What provisioner key do you want to use?
  ▸ acme (ACME)

✔ Provisioner: acme (ACME)
Using Standalone Mode HTTP challenge to validate foo.internal .. done!
Waiting for Order to be 'ready' for finalization .. done!
Finalizing Order .. done!
✔ Certificate: foo.crt
✔ Private Key: foo.key

O de forma no interactiva, especificando el nombre de su proveedor ACME con la --provisionerbandera:

$ sudo step ca certificate foo.internal foo.crt foo.key --provisioner acme

Automatización de renovaciones

Puede renovar cualquier certificado emitido step-cautilizando step ca renew:

$ step ca renew bar.crt bar.key --force

Puede ejecutar step ca renewa través cronde , pero una mejor opción es ejecutar stepen --daemonmodo bajo un supervisor de proceso comosystemd para mantenerlo en ejecución:

$ cat <<EOF | sudo tee /etc/systemd/system/step.service > /dev/null
[Unit]
Description=Automated certificate management
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=mmalone
ExecStart=/usr/bin/step ca renew --daemon /home/mmalone/foo.crt /home/mmalone/foo.key

[Install]
WantedBy=multi-user.target
EOF

Iniciar el servicio:

$ sudo systemctl start step

Y dile systemdque lo reinicie al reiniciar:

$ sudo systemctl enable step

Obtener certificados de Let’s Encrypt

A diferencia de otros clientes ACME, se stepconecta step-cade forma predeterminada. Para obtener un certificado de la CA de Let’s Encrypt, debemos indicarle stepque use la URL del directorio ACME de Let’s Encrypt:

$ sudo step ca certificate acme.step.toys acme.crt acme.key \
    --acme https://acme-v02.api.letsencrypt.org/directory

step ca certificatesolo admite el http-01reto. Al igual que certboty acme.sh, puede funcionar en modo independiente o en modo webroot .

Caddy es un servidor web HTTP/2 con HTTPS automático alimentado por un cliente ACME integrado. Además de servir sitios web estáticos, Caddy se usa comúnmente como un proxy de puerta de enlace API que termina en TLS . Es muy fácil de usar y seguro de forma predeterminada.

carrito v2

Caddy v2 se envía con un servidor ACME incorporado que utiliza las bibliotecas de código abierto de smallstep para emitir certificados para direcciones internas y locales.

carrito v1

Para obtener un certificado de step-caCaddy, debe:

Señale a Caddy en la URL de su directorio ACME usando la tls.cadirectiva en su Caddyfile
Dígale a Caddy que confíe en su certificado raíz usando la LEGO_CA_CERTIFICATESvariable de entorno

Para demostrarlo, crea uno Caddyfileque se parezca a:

foo.internal {
  root /var/run/www
  tls mike@example.com {
    ca https://ca.internal/acme/acme/directory
  }
}

En el mismo directorio, configure la LEGO_CA_CERTIFICATESvariable de entorno y ejecute caddypara comenzar a servir HTTPS.

$ LEGO_CA_CERTIFICATES=$(step path)/certs/root_ca.crt caddy

Podemos comprobar nuestro trabajo con curl:

$ curl https://foo.internal --cacert $(step path)/certs/root_ca.crt
Hello, TLS!

Nginx no es compatible con ACME de forma nativa, pero puede usar un cliente ACME de línea de comandos para obtener certificados para que los use Nginx.

Aquí hay un ejemplo nginx.confque ejecuta Nginx en una configuración común: terminación de TLS y transferencia a un servidor backend que escucha en loopback local:

server {
    listen 443 ssl;
    server_name foo.internal;

    ssl_certificate /path/to/foo.crt;
    ssl_certificate_key /path/to/foo.key;

    location / {
        proxy_pass http://127.0.0.1:8000
    }
}

No hay nada mágico aquí. Solo le estamos diciendo a nginx que escuche en el puerto 443 usando TLS, con un certificado y una clave privada almacenada en el disco. Otros recursos brindan una explicación más completa de las diversas opciones de configuración de TLS de Nginx.

Podemos iniciar un servidor HTTP usando pythony verificar nuestro trabajo con curl:

$ echo "Hello TLS!" > index.html
$ python -m SimpleHTTPServer 8000 &
$ curl https://foo.internal --cacert $(step path)/certs/root_ca.crt
Hello TLS!

Nginx solo lee los certificados una vez, al inicio. Cuando renueve el certificado en el disco, Nginx no lo notará. Por lo tanto, después de cada renovación deberá ejecutar nginx -s reload.

Puede usar la --execbandera para step ca renewhacer esto automáticamente:

$ step ca renew --daemon --exec "nginx -s reload" \
    /path/to/foo.crt \
    /path/to/foo.key

Si está utilizando certbot, consulte la --post-hookbandera para hacer lo mismo. Si estás usando acme.shecha un vistazo --reloadcmd.

Apache httpdtiene soporte ACME integrado a través de mod_md. Las v1.x.xversiones solo funcionan con ACMEv1. Las v2.x.xversiones son compatibles con ACMEv2 pero, desafortunadamente, tuve problemas para mod_mdtrabajar a step-catiempo para esta publicación. Por ahora, podemos implementar certificados en Apache de la misma manera que lo hicimos para Nginx: usando un cliente ACME de línea de comandos, configurando Apache para cargar un certificado y una clave desde el disco, y señalando al servidor después de las renovaciones de certificados.

Aquí hay un ejemplo de configuración de Apache, usando certificados emitidos step-causando certbot:

<VirtualHost *:443>
    ServerName foo.internal
    DocumentRoot /home/mmalone/www
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/foo.internal/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/foo.internal/privkey.pem
</VirtualHost>

Inicie Apache y verifique nuestro trabajo con curl:

$ curl --cacert $(step path)/certs/root_ca.crt https://foo.internal
Hello TLS

Al igual que Nginx, Apache debe señalarse después de que se renueven los certificados mediante la ejecución de apachectl graceful.

Traefik es un proxy inverso moderno con soporte integrado para ACME. Está diseñado principalmente para manejar el ingreso de un clúster de cómputo, enrutando dinámicamente el tráfico a microservicios y aplicaciones web.

Para obtener un certificado de step-caTraefik es necesario:

Señale a Traefik en la URL de su directorio ACME usando la caServerdirectiva en su archivo de configuración
Dígale a Traefik que confíe en su certificado raíz usando la LEGO_CA_CERTIFICATESvariable de entorno

Aquí hay un traefik.tomlarchivo de ejemplo que configura Traefik para terminar TLS y proxy a un servicio que escucha en localhost:

defaultEntryPoints = ["http", "https"]

[entryPoints]
  [entryPoints.http]
  address = ":80"
  [entryPoints.https]
  address = ":443"
    [entryPoints.https.tls]

[acme]

storage = "acme.json"
caServer = "https://ca.internal/acme/acme/directory"
entryPoint = "https"

[acme.httpChallenge]
entryPoint = "http"

[[acme.domains]]
main = "foo.internal"

[file]

[frontends]
  [frontends.foo]
  backend = "foo"

[backends]
  [backends.foo]
    [backends.foo.servers.server0]
      url = "http://127.0.0.1:8000"

Inicie Traefik ejecutando:

$ LEGO_CA_CERTIFICATES=$(step path)/certs/root_ca.crt traefik

Inicie un servidor HTTP para que Traefik actúe como proxy y pruebe con curl:

$ echo "Hello TLS!" > index.html
$ python -m SimpleHTTPServer 8000 &
$ curl https://foo.internal --cacert $(step path)/certs/root_ca.crt
Hello TLS!

legoes una biblioteca cliente ACME escrita en Go. Puede usarlo para obtener un certificado de forma step-caprogramática. Un ejemplo completo de grado de producción es demasiado largo para insertarlo en esta publicación, pero aquí hay una idea general . Las partes que son más relevantes para nuestra discusión son aquellas en las que:

Apunte legoa la URL de su directorio ACME configurandolego.Config.CADirUrl
Dígale legoque confíe en su CA configurando unahttp.Client que confíe en su certificado raíz y diciéndole legoque la use

Obtenga las dependencias requeridas e inicie el servidor:

$ go get golang.org/x/net/http2
$ go get github.com/go-acme/lego
$ go run acme.go

Luego prueba con curl:

$ curl https://foo.internal:5443 --cacert $(step path)/certs/root_ca.crt
Hello, TLS!

El servidor está configurado para verificar los certificados de los clientes si se envían (es decir, está configurado para admitir TLS mutuo). El controlador verifica si se proporcionó un certificado de cliente y responde con un saludo personalizado si lo fue.

Podemos obtener un certificado de cliente step-causando un proveedor OAuth/OIDC :

$ step ca certificate mike@example.com mike.crt mike.key
✔ Provisioner: Google (OIDC) [client: <redacted>.apps.googleusercontent.com]
✔ CA: https://ca.internal
✔ Certificate: mike.crt
✔ Private Key: mike.key

Y pruebe TLS mutuo con curl:

$ curl https://foo.internal:5443 \
    --cacert $(step path)/certs/root_ca.crt \
    --cert mike.crt \
    --key mike.key
Hello, mike@example.com!

Con algunos ajustes a este código, puede implementar un control de acceso sólido.

Hay otras buenas opciones para ACME programático en Go. El certmagicpaquete se basa legoy ofrece abstracciones de mayor nivel y más fáciles de usar. El x/crypto/acmepaquete es de nivel más bajo y ofrece más control, pero actualmente implementa una versión preliminar de estandarización previa de ACME que no funciona con step-ca.

certbotestá escrito en Python y expone su acmemódulo como un paquete independiente ( documentos API ). Aquí hay un ejemplo de cómo usarlo para obtener un certificado y servir HTTPS en Python puro.

Las partes interesantes son donde nosotros:

Dirija el cliente ACME a la URL de su directorio ACME
Dígale al cliente ACME que confíe en su CA configurando el cliente HTTP inyectado para verificar los certificados usando su certificado raíz

Para instalar dependencias e iniciar el servidor, ejecute:

$ pip install acme
$ pip install pem
$ python https.py

Luego verifique su trabajo con curl:

$ curl https://foo.internal:10443 --cacert $(step path)/certs/root_ca.crt
Hello, TLS!

Al igual que el ejemplo anterior de Go, este servidor también admite la autenticación opcional del cliente mediante certificados (es decir, TLS mutuo) y verifica si el cliente se autenticó en el controlador :

$ curl https://foo.internal:10443 \
    --cacert $(step path)/certs/root_ca.crt \
    --cert mike.crt \
    --key mike.key
Hello, mike@smallstep.com!

Para Node.js, Publish Lab’sacme-client es un excelente cliente ACMEv2 que es muy fácil de usar. Aquí hay un ejemplo de cómo usarlo para obtener un certificado y servir HTTPS en javascript puro.

Las partes interesantes son donde nosotros:

Dirija el cliente ACME a la URL de su directorio ACME
Dígale al cliente ACME que confíe en su CA configurando el cliente HTTP para verificar los certificados usando su certificado raíz

Para instalar dependencias e iniciar el servidor, ejecute:

$ npm install node-acme-client
$ node acme.js

Luego verifique su trabajo con curl:

$ curl https://foo.internal:11443 \
    --cacert $(step path)/certs/root_ca.crt
Hello, TLS

Una vez más, este servidor admite la autenticación de clientes opcional mediante certificados y comprueba si el cliente se autenticó en el controlador :

$ curl https://foo.internal:11443 \
    --cacert $(step path)/certs/root_ca.crt \
    --cert mike.crt \
    --key mike.key
Hello, mike@smallstep.com

Kubernetes, bases de datos, colas, administración de configuraciones y más…

Esta publicación es larga, pero está lejos de ser exhaustiva. Muchas cosas funcionan con ACME . Hay módulos para Ansible , Puppet , Chef y Terraform ( ejemplo y más información ).

Para Kubernetes, puede instalar step-causando helm y usar cert-manager junto con uno de los muchos controladores de ingreso que admiten TLS. Los ingresos se utilizan normalmente para representar el tráfico web y API de la Internet pública, a menudo utilizando certificados de Let’s Encrypt. Puede usar para simular esta configuración localmente. También puede configurar un ingreso para usar TLS mutuo en producción, con certificados de , para asegurar el tráfico de servicio a servicio hacia, desde y entre clústeres de Kubernetes sin una VPN o SDN.step-castep-ca

La compatibilidad con ACME está muy extendida, pero se pueden configurar aún más cosas para usar certificados , lo que mejora la seguridad y reduce la carga de administración de secretos. PostgreSQL , MySQL , Cassandra , CockroachDB , Redis , RabbitMQ , Kafka , gRPC , prácticamente todo, se puede configurar para usar TLS mutuo para el cifrado y la autenticación en lugar de usar conexiones inseguras y secretos compartidos. Todo lo que necesita es una CA interna alimentada por step-cay cualquier cliente ACME de línea de comandos para emitir certificados.

Desarrollo local y preproducción

Como demostración final, simulemos Let’s Encrypt localmente con un nuevo aprovisionador ACME llamado «fake-le».

Tendremos que editar$(step path)/config/ca.json manualmente para agregar el aprovisionador y anular step-cala vida útil predeterminada del certificado de 24 horas para que coincida con los 90 días de Let’s Encrypt (2160 horas):

"provisioners": {
    ...
    {
        "type": "acme",
        "name": "fake-le",
        "claims": {
            "maxTLSCertDuration": "2160h",
            "defaultTLSCertDuration": "2160h"
        }
    },
    ...
}

A continuación, agreguemos nuestro certificado raíz al almacén de confianza de nuestro sistema:

sudo step certificate install $(step path)/certs/root_ca.crt

Con nuestro certificado raíz instalado y la duración del certificado que coincide con la de Let’s Encrypt, puede usar cualquier cliente ACME para obtener certificados step-casimplemente cambiando la URL del directorio ACME, tal como lo haría con el entorno de ensayo de Let’s Encrypt .

La instalación del certificado raíz significa que otros clientes TLS también confiarán en los certificados emitidos por step-ca. No necesitará --cacerty curlno recibirá advertencias de certificado en su navegador. Los certificados emitidos por step-cafuncionarán exactamente como los certificados de Let’s Encrypt en cualquier sistema con su certificado raíz instalado.

Barra de direcciones del navegador que muestra la conexión HTTPS a localhost

Si desea conectarse desde otra máquina, también deberá instalar su certificado raíz allí. Puedes usar step ca rooto step ca bootstrappara ayudar con esto.

Tenga en cuenta que la instalación de certificados es una operación global: su navegador y muchas otras cosas que se ejecutan en su sistema confiarán en los certificados emitidos por su CA. Solo debe instalar un certificado raíz si realmente confía en la CA (y en la persona que la ejecuta). Puede desinstalar un certificado raíz cuando no lo esté utilizando para mitigar este riesgo:

sudo step certificate uninstall $(step path)/certs/root_ca.crt

El soporte de ACME en step-caes un cambio de juego. Es genial para probar. Más importante aún, step-caACME hace que ejecutar su propia CA y obtener certificados emitidos sea tan fácil que usar TLS debería ser una obviedad para toneladas de casos de uso de producción.

Pruébelo en código abierto y no se avergüence de esas estrellas de GitHub (a nuestros inversores les encantan):

	paso clic
	certificados de pasos

Alternativamente, puede comenzar a usar ACME ahora mismo con Smallstep Certificate Manager : es gratis para un solo usuario y puede obtener su primer certificado TLS en menos de tres minutos.

Ejecute su propio servidor privado de CA y ACME usando step-ca

¿Por qué ACME?

Uso de ACME con Smallstep Certificate Manager

Uso de ACME con`step-ca`

Habilitación de ACME

Configuración de clientes

Dirigir a los clientes a la URL correcta del directorio ACME

Indicar a los clientes que confíen en el certificado raíz de su CA

Ejemplos

Obtener certificados de`step-ca`

Automatización de renovaciones

Obtener certificados de Let’s Encrypt

carrito v2

carrito v1

Kubernetes, bases de datos, colas, administración de configuraciones y más…

Desarrollo local y preproducción

Translate:

Recent Posts

Recent Comments

Entradas recientes

Atareao.es

PodcastLinux

Archivos

Categorías

Meta

Archives

Categories

Ejecute su propio servidor privado de CA y ACME usando step-ca

¿Por qué ACME?

Uso de ACME con Smallstep Certificate Manager

Uso de ACME constep-ca

Habilitación de ACME

Configuración de clientes

Dirigir a los clientes a la URL correcta del directorio ACME

Indicar a los clientes que confíen en el certificado raíz de su CA

Ejemplos

Obtener certificados destep-ca

Automatización de renovaciones

Obtener certificados de Let’s Encrypt

carrito v2

carrito v1

Kubernetes, bases de datos, colas, administración de configuraciones y más…

Desarrollo local y preproducción

Translate:

Recent Posts

Recent Comments

Entradas recientes

Atareao.es

PodcastLinux

Archivos

Categorías

Meta

Uso de ACME con`step-ca`

Obtener certificados de`step-ca`