Hola de nuevo, querido lector. El segundo capítulo sobre Let's Encrypt adventures en el panel
ISPmanager se declara abierto. En un
artículo anterior, discutimos el complemento para ACME v01. En esto, hablaremos sobre su evolución desde el punto de vista de la lógica de trabajar con el usuario y, por supuesto, sobre el protocolo ACME v02 con soporte para certificados comodín.
Cuidado excesivo
Intentando rodear al usuario con cuidado, puedes llegar lejos. Hasta el momento no podrá trabajar con la funcionalidad en absoluto. Y la primera parte de nuestra historia es solo sobre eso.
Al desarrollar el módulo, queríamos salvar al cliente de una larga preparación para la emisión del certificado. Se introdujeron dos restricciones para esto: permitieron ordenar SSL solo para dominios web registrados en el panel y solo para los alias de dominio que el panel conoce.
Ambas restricciones parecían lógicas. El primero no permitía pedir certificados para dominios inexistentes y producir entidades "muertas", certificados que no se emitirían, porque no hay ningún lugar para colocar los tokens de verificación. El segundo también eliminó entidades innecesarias, y aún no permitía pedir certificados para "*." - alias - en ese momento
LE simplemente no admitía dichos certificados.
Todo estuvo bien hasta que un día apareció en
LE una función para verificar un dominio a través de registros DNS y la capacidad de pedir un certificado para un dominio de correo. Luego, al ordenar un dominio de correo, decidimos agregar lo siguiente a los alias: "mail", "pop", "smtp" - después de todo, la mayoría de las veces los certificados están conectados a ellos. Al final, resultó mal: hubo usuarios que inicialmente configuraron sus servidores de correo con alias completamente diferentes. Debido a nuestras limitaciones en el pedido, no pudieron agregar los nombres requeridos.
Afortunadamente, nos dimos cuenta rápidamente y corregimos el error, permitiendo a los usuarios especificar los datos necesarios al solicitar un certificado. Aún así, a veces hay demasiadas preocupaciones :).
Comodín
Ahora hablemos de cambiar a
ACME v02 , porque solo en esta versión del protocolo
LE apareció la compatibilidad con los certificados comodín. Comencemos con un directorio nuevo, o más bien modificado:
curl -o- 'https://acme-v02.api.letsencrypt.org/directory' { "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change", "mIU2Y2m2FsA": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417", "meta": { "caaIdentities": [ "letsencrypt.org" ], "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf", "website": "https://letsencrypt.org" }, "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct", "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce", "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order", "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert" }
La primera y más obvia diferencia es que las teclas son diferentes :). En mi opinión, se han vuelto mucho más intuitivos. La segunda diferencia es una URL separada para obtener Replay-Nonce. Esto ahora se hace así:
curl -LD - 'https://acme-v02.api.letsencrypt.org/acme/new-nonce' HTTP/1.1 204 No Content Server: nginx Replay-Nonce: QQgdAERh1MLQ6LHC0SVmB9OJXBcEWnwGB53CP0V4JlQ X-Frame-Options: DENY Strict-Transport-Security: max-age=604800 Expires: Sat, 02 Jun 2018 09:49:47 GMT Cache-Control: max-age=0, no-cache, no-store Pragma: no-cache Date: Sat, 02 Jun 2018 09:49:47 GMT Connection: keep-alive
Nonce, por supuesto, será útil para nosotros más de una vez.
Ahora hablemos de los cambios no obvios que conlleva la transición a ACME v02.
Por si acaso, permítanme recordarles cómo se veía nuestra antigua solicitud POST para comunicarse con la primera versión de
ACME :
{ "header": jws,
Ahora la estructura de datos general será diferente:
{ "protected": Base64Url(protected), "payload": Base64Url(payload),
Como puede ver, el campo de encabezado ha sido cancelado. La etapa preparatoria, para gran alegría de los "amantes de la criptografía" como yo, no ha cambiado en absoluto: necesitaremos las mismas llaves rsa,
JWK y
JWS (más sobre esto
en la primera parte ).
Registro
Para registrar un usuario, solo necesita aceptar el acuerdo de usuario y enviar una solicitud de "nueva Cuenta" desde el directorio.
payload = {"termsOfServiceAgreed": true}
Y compila el correcto protegido:
{ "alg" : "RS256", "jwk" : jwk, \\ JSON Web Key “url” : url, \\ “nonce” : Replay-Nonce \\ }
Formamos el cuerpo de la solicitud, la enviamos y ... ¡tómate nuestro tiempo! Procese cuidadosa y cuidadosamente los encabezados de respuesta de
ACME . Encontramos un encabezado llamado
Ubicación y guardamos su contenido. Este es el llamado
KID : la clave de identificación del nuevo usuario registrado. Todas las solicitudes posteriores deberán contener este valor en protegido en lugar de
JWK .
Tenga cuidado : si continúa enviando solicitudes de acuerdo con el esquema anterior, solo los mensajes de error serán la respuesta.
Aquí está nuestro subsiguiente protegido:
{ "alg" : "RS256", "kid" : kid, \\ “url” : url, \\ “nonce” : Replay-Nonce \\ }
Orden de certificado
Nos estamos preparando para enviar una solicitud al directorio ["newOrder"]. Agregamos a la carga útil todos los alias de nuestro dominio web para los que vamos a emitir un certificado:
payload ={ "identifiers":[ { "type":"dns", "value":"name1" }, ... { "type":"dns", "value":"nameN" } ] }
Tenga en cuenta que si desea emitir un certificado comodín, los nombres deben contener solo el nombre principal y "*", un alias. La presencia de cualquier otro nombre dará como resultado un error de lanzamiento.
En la respuesta, obtenemos un JSON que contiene métodos para confirmar la propiedad del dominio y la URL que se utilizará para completar la emisión del certificado.
{ "status":"pending", "expires":"2018-06-08T08:05:49.437251947Z", "identifiers":[ { "type":"dns", "value":"name1" }, { "type":"dns", "value":"www.name1" } ], "authorizations":[
Además, recibimos instrucciones detalladas sobre los cheques:
curl -o- 'https://acme-v02.api.letsencrypt.org/acme/authz/Xp0a_...' { "identifier":{ "type":"dns", "value":"name1" }, "status":"pending", "expires":"2018-06-08T08:05:49Z", "challenges":[ { "type":"http-01", "status":"pending", "url":"https://acme-v02.api.letsencrypt.org/acme/challenge/Xp0a_.../4906756205", "token":"Me_cKM2Stu3iyCJQWEssho8Kj2nvRKuSJvIPF5tRyko" }, { "type":"dns-01", "status":"pending", "url":"https://acme-v02.api.letsencrypt.org/acme/challenge/Xp0a_.../4906756206", "token":"p-0xyySPQClTXVlgTxwJUvVOQtdHmNPpFht95bWrq8s" } ] }
El proceso de confirmación no es diferente de lo que se implementó para
ACME v01 .
Tenga en cuenta: para un certificado comodín, debe seleccionar la confirmación "dns-01".
Obteniendo un Certificado
Después del procedimiento de confirmación, queda por llamar a la URL
Finalizar . Son posibles retrasos leves, por lo tanto, se debe realizar una solicitud GET a esta dirección hasta que obtengamos lo siguiente en la respuesta:
{ "status": "valid",
El certificado ya contendrá una cadena, por lo que está completamente listo para trabajar.
En comparación con la primera, la segunda versión de
ACME se ha vuelto mucho más conveniente y comprensible. La integración de escritura se ha vuelto aún más fácil, dado que la "criptografía" en sí misma no ha cambiado. Observaré con interés el desarrollo de esta increíble herramienta y, sin duda, volveré aquí con información nueva si se producen cambios importantes y útiles.