Verificación básica de certificados La verificación básica de certificados se realiza en todos los certificados en una secuencia y consta de una serie de comprobaciones. Se realizan verificaciones usando cada uno de los cuatro grupos de variables de estado para determinar si el

Comprobación de validez del certificado Esta comprobación tiene éxito si la fecha y la hora actuales en el momento de la validación están dentro del período de validez.

Comprobación del estado del certificado Esta comprobación tiene éxito si el emisor no ha revocado el certificado. Las listas CAC son el medio principal para verificar el estado de un certificado, pero se pueden utilizar otros medios alternativos.

Verificación de la firma del certificado La firma del certificado se puede verificar en función del primer grupo de variables de estado utilizando la clave pública del emisor del certificado, utilizando los parámetros correctos y utilizando el algoritmo de firma digital.

Preparación del próximo certificado En primer lugar, se realiza una validación simple del certificado de CA. Luego, las variables de estado se actualizan para reflejar los valores de los campos complementarios del certificado. Hay varias adiciones que se encuentran

Finalización del procesamiento del certificado Cuando se completa el procesamiento del certificado de entidad final, los valores de salida se establecen en función de los valores de las variables de estado. firma digital. En el campo de información

3.3.1. Formato RSS Puede leer las noticias del sitio de diferentes maneras. La forma más fácil es visitar el sitio de vez en cuando y ver nuevos mensajes. Puedes poner un programa que se conecte a un canal de noticias y él mismo reciba titulares o anotaciones de noticias, según

Formato de certificado X.509 X.509 es otro formato muy común. Todos los certificados X.509 cumplen con el estándar internacional ITU-T X.509; por lo tanto (teóricamente) un certificado X.509 creado para una aplicación puede usarse en cualquier otra,

Revocación de certificado Un certificado solo se puede utilizar mientras sea válido. Es peligroso confiar en que un certificado sea seguro y confiable para siempre. En la mayoría de las organizaciones y todas las PKI, un certificado tiene una vigencia limitada. Esto reduce el período en el que

Notificación de revocación de certificado Una vez que se ha revocado un certificado, es extremadamente importante notificar a todos los posibles corresponsales que ya no es válido. La forma más sencilla de notificar en un entorno PGP es colocar un certificado revocado en

El formato ELF El formato ELF tiene varios tipos de archivos que hemos llamado de manera diferente hasta ahora, como un archivo ejecutable o un archivo de objeto. Sin embargo, el estándar ELF distingue entre los siguientes tipos:1. Un archivo reubicable que contiene instrucciones y datos que pueden ser

Hay dos tipos de sistemas criptográficos: sistemas de clave secreta (simétricos) y sistemas de clave pública (asimétricos). En términos generales, pero comprensibles, los sistemas simétricos usan la misma clave para las operaciones de cifrado y descifrado, mientras que los sistemas asimétricos usan claves diferentes.

En los sistemas simétricos, existe el problema de distribuir la clave secreta de forma segura: ambas partes que intercambian información deben conocer esta clave, pero nadie más debe tener esta clave.

Los sistemas asimétricos están dispuestos de tal manera que hay dos números en ellos:

• "clave pública del usuario A", que se utiliza para cifrar un mensaje destinado al usuario A,
• "clave privada del usuario A", que utiliza este usuario para descifrar los mensajes que se le envían.

Esta última circunstancia es muy importante: el usuario puede publicar su clave pública en lugares públicos para que cualquiera pueda usarla y cifrar un mensaje para A. Por lo tanto, desaparece el problema de distribuir la clave secreta.

El usuario debe mantener su clave privada en secreto de los extraños: desea que solo el usuario pueda descifrar los mensajes que se le enviaron. Además, el requisito de que la clave privada se mantenga en secreto es muy importante en relación con el concepto de firma digital, que se analiza un poco más adelante. De cara al futuro, digamos que el secreto de la clave privada también es importante porque solo el usuario debería poder crear su propia firma digital, que depende del valor de la clave privada.

Muy a menudo, la clave privada se almacena en los medios en forma cifrada y se descifra solo durante la duración de algunas acciones que requieren el conocimiento de la clave privada. Esto aumenta ligeramente la seguridad de almacenar la clave privada, pero crea un inconveniente si algún tipo de servicio automático necesita la clave privada: (al menos) cada vez que se inicia este servicio, debe ingresar una contraseña para descifrar la clave.

También hay tarjetas inteligentes que pueden realizar operaciones criptográficas dentro de sí mismas, dando solo el resultado a la salida, pero sin revelar el contenido de la clave privada. Robar una clave privada de una tarjeta inteligente correctamente implementada debería ser muy difícil. La clave privada, incluso almacenada en una tarjeta inteligente, puede protegerse con contraseña. Si no hay contraseña, cualquier persona con una tarjeta inteligente en sus manos puede realizar acciones que requieren el conocimiento de la clave privada: el valor de la clave privada en sí permanecerá en secreto, pero será posible realizar cualquier acción prevista con él. .

Firma digital

Los sistemas de clave pública tienen otra característica interesante: el usuario puede crear una firma digital que, cuando se coloca documento digital, puede servir como garantía de que el usuario, y no otra persona, firmó realmente este documento.

El esquema es conceptualmente simple: el usuario A, utilizando su clave privada, realiza alguna operación sobre los datos que quiere firmar y pasa el resultado junto con los datos originales a cualquier otro objeto. Y este mismo objeto, usando solo la clave pública del usuario A, puede verificar fácilmente que la firma digital es correcta.

Resaltamos una vez más que la condición de accesibilidad de esta clave privada solo a su propietario juega un papel muy importante: si se cumple, entonces el usuario no puede rechazar su firma digital. Esto se llama no repudio.

Uno de los usos de una firma digital es la autenticación de objetos. La autenticación es el proceso de establecer la "identidad" de un objeto. Está claro que si un objeto puede firmar digitalmente, esta firma se puede verificar y el objeto se asocia con su clave pública. El último ingrediente que falta en este esquema de autenticación es el punto en el que la clave pública y el objeto en sí están vinculados: necesitamos saber exactamente quién es el propietario de esta clave pública.

autoridad de certificación

El problema de vincular una clave pública y algún objeto se puede resolver de diferentes formas. Uno de los enfoques más simples es hacer una lista de claves públicas coincidentes y "nombres" de objetos. El nombre puede ser cualquier identificador, como el nombre de dominio de una máquina, nombre completo, apellido y patronímico de una persona, etc.; el problema de la unicidad de los nombres, que necesariamente debe aparecer, es una dificultad separada, que generalmente se resuelve por medios administrativos, como un sistema de espacio de nombres jerárquico y algún tipo de sistema de resolución de conflictos de nombres dentro del mismo subespacio de nombres. Este tema no se discutirá más aquí.

Pero el enfoque de la lista de coincidencias es muy débil en la escala, porque estas mismas listas deben sincronizarse en todas partes del mundo (o más bien, en la parte del mundo donde se usan estas listas).

Por lo tanto, se introdujeron los conceptos de un certificado X.509 y una autoridad de certificación. Un certificado X.509 (en adelante, simplemente un certificado) es un conglomerado de la clave pública del usuario, la información del usuario, un nombre de certificado denominado Nombre distinguido (DN) y una firma digital de una autoridad de certificación que une todos estos datos. Es decir, se hace posible asociar una clave pública y un DN de usuario, que puede servir como el ingrediente deseado en el proceso de autenticación si se utiliza como identificador de usuario el Nombre Distinguido de su certificado. Por cierto, un certificado tiene una fecha de caducidad, lo que limita el período de validez de la coincidencia creada por la CA.

Naturalmente, el problema simplemente se traslada a otro lugar: en lugar de mantener una gran lista de coincidencias, ahora tenemos que mantener una lista significativamente más pequeña de claves públicas de las autoridades de certificación. En este caso, la clave de la autoridad de certificación es suficientemente confiable: la autoridad de certificación confirma la asociación de miles de nombres de usuario con las claves públicas correspondientes.

¿Por qué es necesaria la autenticación? ¿El cifrado por sí solo no es suficiente?

Bueno, en primer lugar, la autenticación es valiosa en sí misma: los sistemas informáticos necesitan autenticar a sus usuarios para luego decidir si autorizan su acceso a varios recursos.

Pero si está tomando la clave pública de un usuario y desea enviarle un mensaje encriptado, entonces probablemente querrá asegurarse de encriptar el mensaje con la clave pública correcta, especialmente si obtiene esa clave de público. fuentes. Después de todo, un atacante puede colocar su clave pública, pero al mismo tiempo indicar que la clave pertenece a su destinatario. Y si no autentica la clave pública, el atacante, después de haber interceptado su mensaje cifrado, podrá descifrarlo sin ningún problema.

Es decir, la introducción de una autoridad de certificación nos permite autenticar el objeto que posee este certificado. Naturalmente, antes de eso, debemos confiar en la clave pública de la autoridad de certificación. Esto implica dos cosas:

1. confianza en una autoridad de certificación en general, es decir, confianza en su reputación,
2. confianza de que la clave pública que obtuvo es realmente la clave pública de esta autoridad de certificación.

• llame al centro de certificación y verifique el contenido de la clave pública por teléfono,
• venga al centro de certificación y tome la clave pública en algún medio,
• confiar en aquellas claves públicas de las autoridades de certificación que ya están presentes en algún paquete de software
• y muchas otras formas que son aún más inconvenientes que las ya mencionadas;))

Certificados de representación

Genial: ahora tenemos CA de confianza, sus claves públicas, certificados de usuario y sus claves privadas. Podemos encriptar mensajes y crear firmas digitales que son difíciles de refutar.

¿Qué otra cosa? En los sistemas multicomponente, lo que se denomina inicio de sesión único es muy conveniente: la capacidad de autenticarse manualmente solo una vez, y todas las demás operaciones de autenticación se llevarán a cabo automáticamente. Esto suele ser cierto en los sistemas que inicialmente lo autentican y luego el sistema comienza a realizar acciones en su nombre, por ejemplo, recibir datos, ejecutar tareas, publicar sus resultados, etc. Esto se llama delegación.

La delegación basada en certificados proxy funciona de la siguiente manera: después de la autenticación mutua del usuario y el servicio que funcionará en nombre del usuario en el futuro, el servicio crea un nuevo par de claves y envía la clave pública al usuario para que la firme. El usuario firma esta clave pública de la misma manera que lo hace una CA, pero utiliza la clave privada del usuario. El certificado resultante se denomina certificado proxy.

El servicio que actúa en nombre del usuario puede entonces autenticarse utilizando su clave privada (recién generada) y un certificado firmado por el usuario. El proceso de autenticación es algo así.

1. Se verifica la firma generada por el servicio. Esto utiliza la clave pública que se envió junto con la firma.
2. Se autentica la clave pública con la que se verificó la firma. Primero, se verifica la firma en el certificado de proxy, que se creó utilizando la clave privada del usuario. Esto se hace usando la clave pública del usuario.
3. De la misma manera, se autentica la clave pública del propio usuario, pero aquí ya se utilizan datos sobre la autoridad de certificación.

Usando el mismo mecanismo, el servicio para el que se emitió originalmente el certificado de proxy puede firmar otro certificado de proxy, delegando la autoridad del usuario a lo largo de la cadena a otro servicio. Así es como se implementa el inicio de sesión único.

• Guía de estilo X.509, escrita por Peter Gutmann. Hay muchos detalles técnicos, pero para algunos vale la pena leerlo.

Formato y Estructura del Certificado de Clave de Firma

Una descripción detallada de la estructura del certificado, incluida una lista de restricciones en el uso de la UPC y el procedimiento para usar los campos de un certificado ES calificado emitido por la CA FC (en adelante, la Descripción de la UPC) es aprobada por el CA FC en forma de documento separado que forma parte integrante de este Reglamento.

Certificado de clave de validación firma electronica en formato electrónico es un documento electrónico que tiene una estructura que corresponde al estándar de la Unión Internacional de Telecomunicaciones ITU-T X.509 versión 3 y las recomendaciones RFC 3280 y 5280 del IETF (Internet Engineering Task Force) y se presenta en codificación Base64.

La estructura de los certificados de clave de firma producidos por la CA viene determinada por la siguiente tabla:

El nombre común o CN se usa generalmente en los certificados SSL. CN se utiliza para definir el nombre del servidor que se utilizará para la conexión SSL segura. Generalmente, este certificado SSL se usa para asegurar la conexión entre un servidor HTTP/S y un navegador cliente como Chrome, Explorer, Firefox.

El nombre común se utiliza para especificar la identidad del host o del servidor. Cuando un cliente intenta conectarse a un servidor remoto como un servidor HTTP, primero obtendrá el certificado SSL de este servidor. Luego compare el nombre de host o el nombre de dominio al que desea conectarse con el nombre común proporcionado en el certificado SSL. Si son iguales, utilizará el certificado SSL para cifrar la conexión.

Nombre común técnicamente representado como campo commonName en la especificación del certificado X.509. La especificación X.509 se usa en los certificados SSL, que es lo mismo.

Podemos formular el nombre del comando como se muestra a continuación.

Nombre común = Nombre de dominio + Nombre de host

Podemos usar los siguientes nombres de dominio y host como nombre común.

sitio www.sitio *.sitio

Nombre de dominio completo (FQDN)

El nombre de dominio completo o FQDN se usa con el nombre de comando intercambiable. El nombre totalmente calificado se utiliza para definir el nombre de host de manera estricta. Se pueden encontrar más detalles sobre el FQDN en el siguiente tutorial.

Nombre de la Organización

El nombre de la organización puede malinterpretarse con el nombre común. Nombre de la organización es el nombre de la organización a la que pertenece la infraestructura de TI. El nombre de la organización no debe usarse como nombre común, lo que creará problemas de seguridad.

Sistema operativo: Linux Debian/Ubuntu.
Aplicación: OpenSSL, Nginx, Apache2.

Aquí está la hoja de trucos más simple del procedimiento para prepararse para la adquisición de un certificado SSL / TLS, verificar su corrección y usarlo en un servicio web, ampliado con algunas explicaciones.

Generamos claves privadas y públicas.

Es muy conveniente realizar trabajos con componentes certificados en un lugar cerrado desde el exterior:

$ mkdir -p ./hacer-cert

$ cd ./hacer-cert
$ openssl genrsa -des3 -out ./example.net.key 2048

El revoltijo de caracteres que vemos en un archivo de clave de texto es en realidad un contenedor de un conjunto ofuscado de bloques generados de acuerdo con el algoritmo RSA de cifrados únicos, y uno de estos bloques, "módulo", es la clave "pública" de el paquete de cifrado asimétrico utilizado en todos los componentes del certificado. Todo el resto del contenido es una clave "privada".

$ openssl rsa -noout -text -in ./example.net.key

Cabe señalar que, en la práctica, cuando un certificado SSL se usa solo para transferir una cantidad de sitios a HTTPS, la mayoría de las personas prefieren no perder el tiempo con un contenedor de claves protegido por contraseña, sino liberarlo inmediatamente de esta protección, creando otro. al lado - "sin contraseña":

$ cd ./hacer-cert
$ openssl rsa -in ./example.net.key -out ./example.net.key.decrypt

El subsistema en sí para proteger el flujo de tráfico a través de SSL / TLS generalmente se implementa en claves simétricas de sesión generadas por el servidor web y el navegador del cliente durante la negociación inicial de la conexión, y algunas claves de cifrado preestablecidas especiales no son necesarias para esto (aunque sí facilitar el procedimiento de negociación - clave DH, por ejemplo). El certificado (del estándar X.509), cuyo conjunto de componentes vamos formando aquí gradualmente, está destinado a una especie de autenticación de un recurso web en la infraestructura de Internet, donde una autoridad de certificación de confianza condicional garantiza la conexión del clave "pública" especificada en el certificado y la descripción del recurso mediante la firma electrónica del contenido del mismo.

Para transferir a la autoridad de certificación nuestra clave "pública" (¡no todo el contenido de la clave "privada", sino solo su bloque "módulo"!) E información sobre el recurso, cuya autenticidad confirmamos, un contenedor CSR especial ( Solicitud de firma de certificado). Lo creamos, especificando un contenedor de estos como fuente de la clave "pública":

$ cd ./hacer-cert
$ openssl req -new -key ./example.net.key -out ./example.net.csr

"Nombre del país": código de país de dos caracteres según ISO-3166 (RU - para Rusia);
"Nombre del Estado o Provincia" - el nombre de la región o región;
"Nombre de la localidad" - el nombre de la ciudad o localidad;
"Nombre de la organización" - nombre de la organización;
"Nombre de la unidad organizativa" - nombre de la unidad (campo opcional);
"Nombre común": el nombre de dominio completo del recurso (FQDN) para el que se solicita el certificado;
"Dirección de correo electrónico": dirección de correo electrónico de contacto del administrador del nombre de dominio (campo opcional);
"Una contraseña de desafío" - (campo opcional, no completado);
"Un nombre de empresa opcional": un nombre de empresa alternativo (campo opcional, sin rellenar).

Los curiosos pueden ver lo que se esconde en el código del contenedor CSR:

$ openssl req -noout -text -in ./example.net.csr

Adquisición de un certificado SSL/TLS (X.509).

Los matices de elegir un proveedor de certificados, los procedimientos de pedido y pago no se consideran aquí, no se trata de un problema técnico. Uno de los puntos importantes es no perder la elección entre un certificado destinado a un dominio y un "comodín" que cubra todos los subdominios del siguiente nivel con sus garantías.

Generación de un certificado X.509 autofirmado (opcional).

Alternativamente, para uso exclusivo en una red local, puede crear el certificado requerido usted mismo firmándolo con su clave "privada" en lugar de centro de confianza certificación - el llamado "autofirmado" (autofirmado):

$ cd ./hacer-cert
$ openssl x509 -req -days 1095 -in ./example.net.csr -signkey ./example.net.key -out ./example.net.crt

Comprobación de la corrección de certificados y claves.

El certificado SSL/TLS recibido contiene al menos la siguiente información:

Versión del certificado;
Número de serie del certificado;
Algoritmo de firma;
El nombre completo (único) del propietario del certificado;
La clave pública del propietario del certificado;
Fecha de emisión del certificado;
Fecha de vencimiento del certificado;
El nombre completo (único) de la autoridad de certificación;
Firma digital del editor.

$ cd ./hacer-cert
$ openssl x509 -noout -text -in ./example.net.crt

La forma más sencilla de verificar la exactitud de la clave "privada", la CSR y el certificado X.509 final es verificar la suma de verificación de la clave "pública" (bloque "módulo") contenida en todos estos contenedores:

$ openssl rsa -noout -modulus -in ./example.net.key | abre SSL md5
$ openssl req -noout -modulus -in ./example.net.csr | abre SSL md5
$ openssl x509 -noout -modulus -in ./example.net.crt | abre SSL md5

Formamos un conjunto típico de certificados y archivos de claves.

Normalmente, las autoridades de certificación proporcionan no solo el certificado solicitado, sino también un conjunto adicional de certificados intermedios (la propia autoridad, su nodo principal, etc. hasta el nodo raíz).

En general, en el proceso podemos acumular varios archivos, los cuales nombro de acuerdo a su funcionalidad, algo así:

"example.net.key" - contenedor con claves "privadas" y "públicas" (protegidas con contraseña);
"example.net.key.decrypt": contenedor no protegido por contraseña con claves "privadas" y "públicas";
"example.net.csr": la solicitud de CSR utilizada al solicitar el certificado;
"example.net.crt" - directamente nuestro certificado X.509;
"intermediate.crt" - certificado (o una cadena de este) de la autoridad de certificación;
"raíz.crt" - certificado centro de la raíz desde donde comienza la cadena de confianza.

$ cd ./hacer-cert
$ cat ./ejemplo.net.crt >> ./ejemplo.net-chain.crt
$ cat ./intermedio.crt >> ./ejemplo.net-chain.crt
$ cat ./root.crt >> ./example.net-chain.crt

En Linux, los certificados y las claves de cifrado ya tienen lugares en el sistema de archivos. Distribuimos archivos y los protegemos del acceso de extraños:

# mkdir -p /etc/ssl/certificados
# mkdir -p /etc/ssl/privado

# cp ./ejemplo.net-chain.crt /etc/ssl/certs/
# cp ./example.net.key.decrypt /etc/ssl/private/

# chown -R raíz:raíz /etc/ssl
# chmod -R o-rwx /etc/ssl

En el caso más simple, el uso de un certificado SSL en el servidor web "Nginx" se implementa aproximadamente de la siguiente manera:

# vi /etc/nginx/sites-enabled/example.net.conf

....

servidor(
escuchar 443 ssl;
nombre_servidor ejemplo.net;
....

SSL activado;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
protocolos_ssl SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers AES256-SHA:RC4:HIGH:!aNULL:!MD5:!kEDH;
ssl_prefer_server_ciphers en;
ssl_session_cache compartido:SSL:30m;
ssl_session_timeout 1h;

certificado_ssl /etc/ssl/certs/example.net-chain.crt;
ssl_certificate_key /etc/ssl/private/example.net.key.decrypt;
....
}
....

En el servidor web "Apache", el certificado SSL se usa así:

# vi /etc/apache2/sites-enabled/example.net.conf

....
# Descripción del entorno de trabajo del sitio web accesible a través de HTTPS

ServerName ejemplo.net
....

# Configuración de protocolo genérico recomendada
Motor SSL activado
Protocolo SSL todos -SSLv2
SSLHonorCipherPedido en
SSLCipherSuite HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!aECDH:+SHA1:+MD5:+HIGH:+MEDIUM
SSLOptions +StrictRequire
Compresión SSL desactivada

# Certificado y archivos clave
SSLCertificateFile /etc/ssl/certs/example.net-chain.crt
SSLCertificateKeyFile /etc/ssl/certs/example.net.key.decrypt

....