Este artículo explicará cómo utilizar los certificados emitidos por una Autoridad de Certificación (CA) de terceros, como Let's Encrypt, Comodo, Symantec, Digicert, etc. También cubrirá cómo funcionan los certificados en general.
Sinopsis
Los certificados tienen dos propósitos principales: cifrar la comunicación entre dos entidades y confirmar la autenticidad de la entidad. El primero puede ser otorgado por un certificado autofirmado, pero para autenticar la entidad, necesita un certificado de confianza global emitido por una CA raíz o intermedia. Este artículo explicará cómo los certificados generalmente logran esta autenticación, cómo cambiar el formato del certificado para que funcione con otros dispositivos, incluidos nuestros firewalls, cómo importar el certificado a su firewall y cómo deben manejarse los certificados para evitar riesgos de seguridad.
Tabla de contenidos
- ¿Cómo funciona un certificado?
- Certificados autofirmados
- Trabajar con certificados
- Importación de certificados en firewalls USG / ATP
- Seguridad del certificado
¿Cómo funciona un certificado?
Cada certificado consta de dos partes: el certificado (también llamado clave pública) y la clave privada. El certificado se puede compartir públicamente y simplemente contiene información sobre los propósitos para los cuales se emitió el certificado y para qué entidad se emitió el certificado; esto puede ser su FQDN, dirección de correo electrónico u otro valor.
Los certificados tienen un período de validez limitado; esto ayuda en situaciones en las que algún certificado antiguo con una clave privada se desenterra en algún lugar después de décadas. Si la validez fuera infinita, el certificado aún podría ser utilizado con fines maliciosos por cualquiera que lo tenga en sus manos. A partir de 2021, se recomienda no utilizar un período de validez superior a un año. Con la llegada de los mecanismos de reemisión automática como CertBot, este período puede acortarse mucho para mejorar aún más la seguridad.
Los certificados se pueden revocar en caso de que se filtre la clave privada y, como medida de precaución, cualquier violación de seguridad que comprometa el hardware que contiene claves privadas debe ir seguida de una revocación del certificado y la posterior reemisión de nuevos certificados.
Los certificados se pueden emitir a varias entidades, como FQDN, correo electrónico, incluso dirección IP o nombre de pila. Si bien es técnicamente posible tener certificados FQDN comodín y los usuarios los prefieren a menudo, tenga en cuenta que en caso de una fuga de clave privada de un servicio específico, el certificado comodín autentica todo el FQDN; como resultado, una fuga del La clave privada en un servidor web que se utiliza para la mera presentación de la empresa también puede utilizarse para ataques MITM entre el servidor Exchange o el sistema CRM. Mantener los certificados independientes para cada subdominio ayuda a mitigar el impacto de la filtración hasta que se revoque el certificado.
Si bien también es posible emitir certificados a direcciones IP, hacerlo está obsoleto. La razón detrás de esto es que las direcciones IP se pueden cambiar fácilmente en comparación con FQDN.
El principio básico de los certificados es bastante simple. En un ejemplo, Alice quiere acceder al servidor de Bob, pero el problema es que ella nunca estuvo allí, por lo que nunca podrían intercambiar algún secreto común para autenticarse. ¿Cómo puede Alice estar segura de que realmente se está conectando con Bob? Aquí es donde entra en juego Charlie. Alice conoce a Charlie y agregó su certificado al depósito de certificados raíz. Por lo tanto, Alice considera a Charlie una entidad de confianza. Si Bob tiene su propio certificado y clave privada emitida por Charlie, puede autenticarse con Alice y no importa que Alice nunca haya estado en contacto con Bob antes, porque Charlie confía en Bob, y como Alice confía en Charlie, ella también confía en Bob. . Esto es algo que se llama Cadena de confianza.
Echemos un vistazo a la Cadena de confianza para nuestro certificado web Support Campus:
Observe que también hay otra entidad llamada R3. Esto se denomina CA intermedia, mientras que DST Root CA X3 es Root CA. El certificado solo puede tener una CA raíz, pero puede haber más CA intermedias. La CA intermedia es una entidad a la que se le ha otorgado permiso para emitir certificados para sus clientes. Siempre que su PC tenga el certificado DST Root CA X3 en la lista de certificados raíz confiables, se considerará confiable a support.zyxel.eu.
Certificados autofirmados
De forma predeterminada, nuestros cortafuegos (y muchos otros dispositivos) utilizan certificados autofirmados para establecer una conexión TLS cifrada. Dicho certificado se informa mediante un mensaje de error conocido por el navegador: 
Hay dos razones por las que esto sucede. La primera razón es que el certificado es básicamente un certificado de CA raíz que no está presente en su sistema. Pero simplemente instalarlo como CA raíz en su computadora no funcionará, porque el certificado no se emite para su IP o dominio. Sin embargo, el certificado es adecuado para una conexión segura y su uso no presenta ningún riesgo de seguridad siempre que no se filtre su clave privada; el único problema aquí es que no se puede confirmar la identidad.
Trabajar con certificados
A lo largo de los años, se desarrollaron muchos formatos de certificado. Sin embargo, los certificados siguen utilizando el mismo principio y todos los formatos se pueden convertir a otros formatos.
Formatos de certificado
El formato más antiguo sería el PEM, que contiene la clave codificada ASCII. La razón detrás de esto es el uso original en correos cifrados, donde el certificado binario puede tener un formato incorrecto. Los PEM son comunes en los sistemas Unix y es probable que su CA le haya enviado un certificado junto con una clave privada en formato PEM. Por lo general, utiliza la extensión de archivo .pem o .cer.
DER es una forma binaria de certificado en formato ASCII PEM. Todos los tipos de certificados y claves privadas se pueden codificar en formato DER. Este formato admite el almacenamiento de un solo certificado y no incluye una clave privada para la CA raíz / intermedia. Tienen extensión .der o .cer y se utilizan con mayor frecuencia en plataformas Java.
PKCS # 7 es un formato binario que permite contener certificados o toda la Cadena de confianza de certificados en un solo archivo. Sin embargo, no se puede almacenar ninguna clave privada en este formato. Las CA utilizan este formato con mayor frecuencia para proporcionar una Cadena de confianza completa. Utiliza la extensión .p7b.
PKCS # 12, también conocido como PFX, es un formato que puede contener toda la Cadena de confianza y también la clave privada. Por lo general, las CA proporcionan este formato, ya que puede protegerse con una contraseña. Usualmente usa la extensión .p12 o .pfx.
Herramientas de certificado
Windows tiene una utilidad de CLI de sistema incorporada certutil que se puede usar para convertir certificados. Los complementos de administración en Microsoft Management Console también permiten la administración de certificados.
La utilidad de código abierto llamada OpenSSL también puede manejar y convertir certificados. Los binarios están disponibles para Windows, Linux y macOS (y muchas otras plataformas)
Comandos de certutil útiles:
Merging PEM into PFX:
C:\temp>certutil –MergePFX cert.cer cert.pfx
NOTE: as certutil doesn't allow to specify private key path, the key must be present
in the same directory as certificate, have the same name and .key extension.
Comandos útiles de OpenSSL:
Merging PEM into PFX:
C:\temp>openssl pkcs12 -export -out cert.pfx -inkey key.pem -in cert.pem
Importación de certificado en firewalls USG / ATP
El diseño actual (a junio de 2021) está restringido a la importación de certificados sin claves intermedias. Si el certificado contiene una clave intermedia, el archivo se analizará incorrectamente y el intento de usar dicho certificado puede resultar en la indisponibilidad del servicio (como WebGUI). Es una buena idea obtener el certificado en formato .pem y exportarlo a formato .pfx usando certutil u OpenSSL. El certificado se puede importar, junto con su contraseña en el siguiente menú:
Configuration > Objects > Certificates > My Certificates
Seguridad del certificado
Cada certificado tiene su respectiva clave privada. Si bien un certificado es información pública, la clave privada debe manejarse como un secreto y no debe ser compartida por nadie. Ni siquiera con nosotros en Zyxel: la única forma válida es utilizar herramientas de asistencia remota como TeamViewer. Al almacenar la clave privada en formato pem, vuelva a verificar los permisos para acceder a la clave privada para evitar su filtración. Utilice siempre el cifrado de contraseña de formato pfx para proporcionar al menos cierto grado de seguridad al exportar certificados. Cualquier certificado con la clave privada filtrada debe revocarse de inmediato.
DESCARGO DE RESPONSABILIDAD:
Estimado cliente, tenga en cuenta que utilizamos la traducción automática para proporcionar artículos en su idioma local. Es posible que no todo el texto se traduzca con precisión. Si hay preguntas o discrepancias sobre la exactitud de la información en la versión traducida, revise el artículo original aquí: Versión original