¿Por qué ACME / Let's Encrypt requiere registros A no CNAME?

Question

¿Por qué ACME / Let's Encrypt requiere registros A no CNAME?

#1 de Søren Boisen (4 votos)
#2 de sebastian nielsen (1 votos)

6

Estoy usando ngrok para demostrar el protocolo ACME en IIS / Windows. Sin embargo, este servicio prefiere CNAME sobre A registros.

Al depurar la interacción, parece que ACME solo permite los registros A. ¿Cuál es la razón de seguridad de este comportamiento? ¿Qué alternativa hay?

Mensaje de error aquí:

    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:connection",
        "detail": "DNS problem: SERVFAIL looking up A for dev.server.com",
        "status": 400
      },

tls dns letsencrypt

pregunta random65537 19.08.2016 - 21:21

fuente

2 respuestas

Lea otras preguntas en las etiquetas tls dns letsencrypt

¿Puedo probar mi propia red? Generar nueva clave - ECC vs RSA

score 4 · Answer 1

La respuesta de sebastian nielsen es errónea en la medida en que el agujero de seguridad estaba en un servicio no relacionado llamado startencrypt. La implicación de que Letsencrypt no admite registros CNAME también es incorrecta según lo verificado por este hilo y varios otros donde los moderadores de Letsencrypt aseguran a las personas que sí admiten registros CNAME. De hecho, acabo de pasar la verificación de un subdominio que he señalado en una máquina virtual de Azure mediante el uso de un registro CNAME.

El mensaje de error que da certbot, cuando algo está mal es bastante engañoso y no pude encontrar nada en los documentos oficiales sobre el soporte de CNAME, lo que lleva a toda esta confusión.

score 1 · Answer 2

El motivo de esto, es que es posible generar certificados para sitios que no posee si permite CNAME.

Hubo un agujero de seguridad, donde se podía configurar un CNAME propio como "yoursite.com CNAME google.com" y luego se pudo generar un certificado para google.com. El mismo problema existía con las redirecciones, en las que podría configurar una redirección y provocar la emisión de un certificado no autorizado.

Sin embargo, en lugar de reparar el agujero real volviendo a verificar la dirección después de haber encontrado un CNAME / redirect, simplemente se bloquearon, por lo que no se permiten los redirects ni los CNAME.