Crear certificados de servidor
Para crear certificados de servidor, genere un archivo PKCS12, JKS o PEM para el servidor, según el servidor que se esté utilizando.
La clave privada la genera la CA y no es necesario crear una solicitud de firma de certificado (CSR) en su servidor para esto.
Para crear certificados de servidor, siga los pasos a continuación:
Paso 1: Crear perfiles
Cree los perfiles deseados (los perfiles de entidad y certificado predeterminados funcionan correctamente, pero quizás sean demasiado genéricos). Su perfil de certificado debe tener:
KeyUsage : Firma digital, cifrado de clave
Uso extendido de la clave : Autenticación del servidor
Paso 2: Crear usuarios
Cree un usuario utilizando RA Web> Realizar nueva solicitud o el comando CLI bin/ejbca.sh ra .
El nombre distinguido (DN) del servidor debe contener el nombre de host completo del servidor ( host.domain.com ) en el campo Nombre común (CN). Ejemplos de DN:
Para un servidor web: C=SE,O=AnaTom,CN= www.anatom.se
Para un servidor de correo: C=SE,O=AnaTom,OU=Ingeniería,CN=mail.anatom.se
También puede especificar el mismo nombre (o varios) como DNSName en SubjectAlternativeNames . Para certificados comodín, utilice *.anatom.se .
Establezca el tipo de token para que coincida con el tipo de token que se debe generar para su servidor.
Paso 3: Establecer contraseña
Para permitir la generación de certificados por lotes, el programa de generación por lotes debe tener acceso a la contraseña del usuario (servidor) para solicitar un certificado en su nombre. Normalmente, la contraseña se almacena en formato hash, por lo que debe almacenarse en texto plano ejecutando:
bin/ejbca.sh ra setclearpwd <username> <password> Paso 4: Generar claves privadas y certificados
Para generar claves privadas y certificados, ejecute:
bin/ejbca.sh batchLos servidores requieren claves y certificados en diferentes formatos:
Formato PEM: Para generar archivos PEM, utilice el tipo de token PEM . Los archivos PEM se almacenan en un subdirectorio independiente , pem . Los archivos PEM generados pueden usarse con Apache, por ejemplo, y no están protegidos por contraseña.
SUN JKS: Para generar archivos JKS, utilice el tipo de token JKS . Los archivos JKS se almacenan en el subdirectorio p12 en lugar de en archivos PKCS12. Los archivos JKS generados pueden usarse con Tomcat, por ejemplo, y están protegidos por la contraseña del usuario (tanto la contraseña de la clave privada como la del almacén de claves).
Si el servidor genera las claves y una solicitud de certificado (CSR) para usted, seleccione el tipo de token Generado por el usuario .
Puede utilizar las páginas web de RA (http://127.0.0.1:8080/ejbca/ra/) Realizar una nueva solicitud con la opción Proporcionada por " para la generación de par de claves para pegar la solicitud y recibir el certificado.
Para utilizar OpenSSL para transformar un archivo PKCS12 al formato PEM, ejecute:
openssl pkcs12 - in pkcs12- file -nodesCopie y pegue la clave privada en el archivo de claves, el primer certificado en el archivo de certificado del servidor y el último en el archivo de certificado de la CA. Si su CA es una CA subordinada a otra CA raíz, es posible que el archivo de certificado de la CA deba contener toda la cadena de certificados. La forma exacta en que su servidor requiere los archivos depende del servidor.
HTTP sobre TLS
Para obtener más información sobre cómo los navegadores validan los nombres en los certificados, consulte RFC2818 :
Si existe una extensión subjectAltName de tipo dNSName, esta DEBE usarse como identidad. De lo contrario, DEBE usarse el campo Nombre Común (más específico) del campo Asunto del certificado. Si bien el uso del Nombre Común es una práctica habitual, está obsoleto y se recomienda a las Autoridades de Certificación que utilicen el dNSName en su lugar. La coincidencia se realiza según las reglas de coincidencia especificadas en [RFC2459]. Si el certificado contiene más de una identidad de un tipo determinado (p. ej., más de un nombre dNSName, se acepta cualquier coincidencia del conjunto). Los nombres pueden contener el carácter comodín *, que se considera coincidente con cualquier componente o fragmento de componente de nombre de dominio. Por ejemplo, *.a.com coincide con foo.a.com, pero no con bar.foo.a.com. f*.com coincide con foo.com, pero no con bar.com. En algunos casos, el URI se especifica como una dirección IP en lugar de un nombre de host. En este caso, la dirección IP subjectAltName debe estar presente en el certificado y debe coincidir exactamente con la IP en el URI.