{"id":30214,"date":"2019-10-31T21:34:16","date_gmt":"2019-10-31T18:34:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ietf-odobrili-acme-eto-standart-dlya-raboty-s-ssl-sertifikatami\/"},"modified":"2019-10-31T21:34:16","modified_gmt":"2019-10-31T18:34:16","slug":"ietf-odobrili-acme-eto-standart-dlya-raboty-s-ssl-sertifikatami","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/ietf-odobrili-acme-eto-standart-dlya-raboty-s-ssl-sertifikatami","title":{"rendered":"IETF aprob\u00f3 ACME: es un est\u00e1ndar para trabajar con certificados SSL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

IETF aprob\u00f3 est\u00e1ndar<\/a><\/noindex> Entorno de Gesti\u00f3n de Certificados Autom\u00e1tico (ACME), que ayudar\u00e1 a automatizar la obtenci\u00f3n de certificados SSL. Explicaremos c\u00f3mo funciona.<\/p>\n

\"IETF<\/a><\/noindex><\/a><\/noindex>
\n\/ Flickr \/ Cliff Johnson<\/a><\/noindex> \/ CC BY-SA<\/a><\/noindex><\/i><\/p>\n

\u00bfPor qu\u00e9 se necesitaba un est\u00e1ndar?<\/h2>\n

\nEn promedio, en la configuraci\u00f3n certificado SSL<\/a><\/noindex> para un dominio, un administrador puede gastar entre una y tres horas. Si se comete un error, tendr\u00e1 que esperar a que la solicitud sea rechazada, solo despu\u00e9s de eso se puede presentar nuevamente. Todo esto dificulta el despliegue de sistemas a gran escala.<\/p>\n

El procedimiento de validaci\u00f3n de dominios puede variar entre cada autoridad de certificaci\u00f3n. La falta de estandarizaci\u00f3n a menudo provoca problemas de seguridad. Es bien conocido el caso<\/a><\/noindex>, cuando debido a un error en el sistema, un CA verific\u00f3 todos los dominios declarados. En tales situaciones, los certificados SSL pueden ser emitidos a recursos fraudulentos.<\/p>\n

El protocolo ACME aprobado por IETF (especificaci\u00f3n RFC8555<\/a><\/noindex>) debe automatizar y estandarizar el proceso de obtenci\u00f3n de certificados. Y la exclusi\u00f3n del factor humano ayudar\u00e1 a aumentar la fiabilidad y la seguridad de la verificaci\u00f3n del nombre de dominio.<\/p>\n

El est\u00e1ndar es abierto, y cualquier persona interesada puede contribuir a su desarrollo. En el repositorio en GitHub<\/a><\/noindex> se han publicado las instrucciones correspondientes.<\/p>\n

\u00bfC\u00f3mo funciona?<\/h2>\n

\nEl intercambio de solicitudes en ACME se realiza a trav\u00e9s de HTTPS utilizando mensajes JSON. Para trabajar con el protocolo, es necesario instalar un cliente ACME en el nodo objetivo, que genera un par de claves \u00fanicas en la primera solicitud al CA. Posteriormente, se utilizar\u00e1n para firmar todos los mensajes entre el cliente y el servidor.<\/p>\n

El primer mensaje contiene informaci\u00f3n de contacto sobre el propietario del dominio. Se firma con la clave privada y se env\u00eda al servidor junto con la clave p\u00fablica. Este verifica la autenticidad de la firma y, si todo est\u00e1 correcto, inicia el proceso de emisi\u00f3n del certificado SSL.<\/p>\n

Para obtener un certificado, el cliente debe demostrar al servidor la propiedad del dominio. Para ello, realiza ciertas acciones que solo son accesibles para el propietario. Por ejemplo, la autoridad de certificaci\u00f3n puede generar un token \u00fanico y pedir al cliente que lo coloque en su sitio web. Luego, el CA forma una solicitud web o DNS para extraer la clave de este token.<\/p>\n

Por ejemplo, en el caso de HTTP, la clave del token debe colocarse en un archivo que ser\u00e1 atendido por el servidor web. Durante la verificaci\u00f3n DNS, la autoridad certificadora buscar\u00e1 la clave \u00fanica en el documento de texto del registro DNS. Si todo est\u00e1 en orden, el servidor confirma que el cliente ha pasado la validaci\u00f3n y la CA emite el certificado.<\/p>\n

\"IETF
\n\/ Flickr \/ Blondinrikard Fr\u00f6berg<\/a><\/noindex> \/ CC BY<\/a><\/noindex><\/i><\/p>\n

Opiniones<\/h2>\n

\nPor palabras<\/a><\/noindex> IETF, ACME ser\u00e1 \u00fatil para administradores que tienen que trabajar con m\u00faltiples nombres de dominio. El est\u00e1ndar ayudar\u00e1 a vincular cada uno de ellos con los SSL requeridos.<\/p>\n

Entre las ventajas del est\u00e1ndar, los expertos tambi\u00e9n destacan varios mecanismos de seguridad<\/a><\/noindex>. Deben garantizar que los certificados SSL se emitan solo a los verdaderos propietarios de los dominios. En particular, para protegerse contra ataques DNS, se aplica un conjunto de extensiones DNSSEC<\/a><\/noindex>, y para protegerse contra DoS, el est\u00e1ndar limita la velocidad de procesamiento de ciertas solicitudes, por ejemplo, HTTP para el m\u00e9todo POST<\/a><\/noindex>. Los propios desarrolladores de ACME recomiendan<\/a><\/noindex> para aumentar la seguridad agregar entrop\u00eda a las solicitudes DNS y realizarlas desde m\u00faltiples puntos de la red.<\/p>\n

Soluciones similares<\/h2>\n

\nPara obtener certificados tambi\u00e9n se aplican protocolos SCEP<\/a><\/noindex> y EST<\/a><\/noindex>.<\/p>\n

El primero fue desarrollado en Cisco Systems. Su objetivo era simplificar el proceso de emisi\u00f3n de certificados digitales X.509 y hacerlo lo m\u00e1s escalable posible. Antes de la llegada de SCEP, este proceso requer\u00eda la participaci\u00f3n activa de administradores de sistemas y escalaba mal. Hoy, este protocolo es uno de los m\u00e1s comunes.<\/p>\n

En cuanto a EST, permite que los clientes PKI obtengan certificados a trav\u00e9s de canales seguros. Usa TLS para la transmisi\u00f3n de mensajes y la emisi\u00f3n de SSL, as\u00ed como para vincular el CSR al remitente. Adem\u00e1s, EST admite m\u00e9todos de criptograf\u00eda de curva el\u00edptica, lo que crea un nivel adicional de protecci\u00f3n.<\/p>\n

Por la opini\u00f3n de los expertos<\/a><\/noindex>, soluciones como ACME deber\u00edan tener una mayor difusi\u00f3n. Ofrecen un modelo simplificado y seguro para configurar SSL, as\u00ed como acelera el proceso.<\/p>\n

Publicaciones adicionales de nuestro blog corporativo:<\/h5>\n

<\/p>\n