Si uno de los principales objetos de la infraestructura de clave pública (PKI) son los certificados X509, entonces el tema central de la PKI son las Autoridades de Certificación (CA). Es la entidad emisora de certificados la que emite certificados, rescinde su validez (revocación de certificados) y confirma su validez. En las páginas de
Habrahabr, puede encontrar varias publicaciones sobre el tema de los certificados digitales utilizando
OpenSSL .
Básicamente, estos artículos discuten el uso
de la utilidad openssl , describen su interfaz de línea de comandos y trabajan con archivos que almacenan todo: claves, solicitudes, certificados, incluida la raíz, etc. Pero si desarrolla un centro de certificación (CA) a gran escala basado en OpenSSL, entonces es natural querer deshacerse de esta variedad de archivos y trabajar con bases de datos, además de tener una interfaz gráfica para emitir y administrar certificados. Y si recuerdan la Ley Federal del 6 de abril de 2011. No. 63- En firmas electrónicas, es necesario que la CA cumpla con los requisitos de esta ley, así como con los Requisitos para el Formulario de Certificado Calificado de un Certificado de Clave de Verificación de Firma Electrónica, aprobado por Orden del Servicio Federal de Seguridad de Rusia del 27 de diciembre de 2011 No. 795.
Los ciudadanos comunes tienen la impresión de que los UT son algo enorme (bueno, el Centro, casi como el Centro de Control de la Misión).
Desde el punto de vista de la responsabilidad de la AC, esto es exactamente así. Después de todo, los certificados emitidos por la CA son realmente iguales en el pasaporte de hoy.
Desde el punto de vista de un programador, no todo es tan aterrador. Así nació el proyecto del centro de certificación CAFL63. La implementación del proyecto CAFL63 se basa en tres "pilares", a saber, OpenSSL,
SQLite3 y
Tcl / Tk .
Entonces, ¿qué es una autoridad de certificación hoy? En primer lugar, es el Centro de registro, donde los representantes de las personas jurídicas, las personas y los empresarios individuales obtienen certificados con un paquete de documentos necesarios, en particular, que identifican la identidad y la autoridad del solicitante. Pueden venir con aplicaciones preparadas electrónicamente. El CR verifica los documentos, la solicitud (datos completados, la exactitud de la firma electrónica, etc.), y si todo va bien, acepte la solicitud, apruebe y envíela al Centro de Certificación (CA). Pero esto es ideal. En la práctica, todo se ve diferente.
Los ciudadanos, las organizaciones necesitan un certificado (para acceder al portal de Servicios del Estado, para informar impuestos, para licitar), pero no saben qué es y qué hacer con él. Están sinceramente convencidos de que la CA recibe una firma electrónica como un facsímil. Pero estos son problemas de iluminación. Por lo tanto, los solicitantes acuden a la Administración Central de la Administración Central y presentan los documentos. Junto con el empleado de la Oficina Central, van a un lugar de trabajo separado y
preparan una solicitud de certificado:
El CR recibe una solicitud preparada en medios electrónicos, como ya se mencionó. ¿Qué necesita recordar el solicitante? En primer lugar, ¡elija los medios con la clave privada creada!
Una solicitud aprobada en medios electrónicos se transmite a la CA, donde se emitirá un certificado sobre la base.
Este es un diagrama esquemático del trabajo de la AC. Los detalles se aclararán a continuación. Una observación, para la conveniencia de la demostración, la utilidad para preparar una solicitud, CR y CA se combinan en un complejo de demostración. Pero no hay problemas con la diversidad funcional. La más simple de ellas es tener una instancia CAFL63 en cada lugar de trabajo y usar solo la funcionalidad requerida.
Cuando el proyecto estaba en pleno apogeo, el proyecto
SimpleCA me llamó la atención. Estudiar este proyecto ayudó mucho con la implementación final de CAFL63 CA.
Puede encontrar el código fuente de la utilidad y sus distribuciones para las plataformas Linux y MS Windows
Entonces, ejecute la utilidad CAFL63 y la página de inicio aparece en la pantalla:
Comenzamos el trabajo presionando la tecla "Crear base de datos". La base de datos de CA se crea utilizando DBMS multiplataforma
SQLite3 . La base de datos de CA contiene varias tablas. La tabla principal mainDB contiene solo un registro, que almacena el certificado raíz, la clave privada cifrada con una contraseña y la configuración de CA. Hay dos tablas relacionadas con las solicitudes de certificados: solicitudes actuales de reqDB y archivo de solicitudes de reqDBArc. Se crean tres tablas para certificados: la tabla de nuevos certificados certDBNew, la tabla del archivo de certificados certDB y la tabla de certificados revocados certDBRev:
. . . certdb eval {create table certDB( ckaID text primary key , nick text, sernum text, certPEM text, subject text, notAfter text, notBefore text, dateRevoke text, state text )} certdb eval {create table certDBRev( ckaID text primary key )} certdb eval {create table certDBNew( ckaID text primary key )} certdb eval {create table reqDB (ckaID text primary key, nick text, sernum text, subject text, type text, datereq text, status text, reqpem text, pkcs7 text)} certdb eval {create table reqDBAr (ckaID text primary key, nick text, sernum text, subject text, type text, datereq text, status text, reqpem text, pkcs7 text)} certdb eval {create table crlDB(ID integer primary key autoincrement, signtype text, issuer text, publishdate text, nextdate text, crlpem text)} . . .
Todas las tablas de solicitud y certificado utilizan
el valor hash (sha1) de la clave pública como clave (clave primaria). Por conveniencia, en el futuro, el valor hash del valor de la clave pública se llamará CKAID (terminología PKCS # 11). Esto resultó ser muy conveniente, por ejemplo, cuando se busca un certificado a pedido o viceversa. Hay otra tabla crlDB en la base de datos que almacena listas de certificados revocados.
El valor de la clave pública se almacena tanto en la solicitud como en el certificado. Por lo tanto, antes de ponerlos en la base de datos, es necesario extraerles la clave pública y calcular el CKAID. Para extraer el valor de la clave pública, es conveniente utilizar el paquete pki (el paquete requiere pki), que contiene herramientas para trabajar con certificados y solicitudes. Sin embargo, este paquete no está diseñado para funcionar con la criptografía rusa. En este sentido, según los procedimientos parse_cert y parse_csr incluidos en el paquete pki, escriba los procedimientos parce_cert_gost y parse_csr_gost:
... ## Convert Pubkey type to string set pubkey_type [::pki::_oid_number_to_name $pubkey_type] # Parse public key, based on type switch -- $pubkey_type { "rsaEncryption" { set pubkey [binary format B* $pubkey] binary scan $pubkey H* ret(pubkey) ::asn::asnGetSequence pubkey pubkey_parts ::asn::asnGetBigInteger pubkey_parts ret(n) ::asn::asnGetBigInteger pubkey_parts ret(e) set ret(n) [::math::bignum::tostr $ret(n)] set ret(e) [::math::bignum::tostr $ret(e)] set ret(l) [expr {int([::pki::_bits $ret(n)] / 8.0000 + 0.5) * 8}] set ret(type) rsa } "1.2.643.2.2.19" - "1.2.643.7.1.1.1.1" - "1.2.643.7.1.1.1.2" { # gost2001, gost2012-256,gost2012-512 set pubkey [binary format B* $pubkey] binary scan $pubkey H* ret(pubkey) set ret(type) $pubkey_type ::asn::asnGetSequence pubkey_algoid pubalgost #OID - ::asn::asnGetObjectIdentifier pubalgost oid1 #OID - ::asn::asnGetObjectIdentifier pubalgost oid2 } default { error "Unknown algorithm" } } ...
A diferencia de los procedimientos "nativos", le permiten trabajar con objetos no solo en formato PEM, sino también en formato DER. Para trabajar con listas de revocación de certificados CRL, se escribió el procedimiento parse_crl. Todos estos procedimientos se pueden encontrar en el código fuente, que se almacena con la distribución.
También en el paquete pki no hay oid-s rusos, por ejemplo, TIN, SNILS, etc. Este problema se resuelve fácilmente agregando oid-s rusos a la matriz :: pki :: oids:
. . . set ::pki::oids(1.2.643.100.1) "OGRN" set ::pki::oids(1.2.643.100.5) "OGRNIP" set ::pki::oids(1.2.643.3.131.1.1) "INN" set ::pki::oids(1.2.643.100.3) "SNILS" # set ::pki::oids(1.2.643.2.2.3) " 34.10-2001" set ::pki::oids(1.2.643.7.1.1.3.2) " 34.10-2012-256" set ::pki::oids(1.2.643.7.1.1.3.3) " 34.10-2012-512" . . .
Teniendo las funciones parse_cert_gost y parse_csr_gost, los valores de CKAID (clave primaria para la base de datos) se calculan de la siguiente manera:
. . . array set b [parse_csr_gost $req] set pem $b(pem) set subject $b(subject) set pubkey $b(pubkey) set key1 [binary format H* $pubkey] set ckaID [::sha1::sha1 $key1] . . .
Entonces, haga clic en el botón "Crear base de datos":
La creación de CA comienza con la elección del directorio en el que almacenaremos la configuración de la base de datos y la contraseña para acceder a la clave privada de CA. La utilidad CAFL63 monitorea cuidadosamente la longitud de la contraseña:
La contraseña se almacena en la base de datos de CA como un hash:
. . . set hash256 [::sha2::sha256 $wizData(capassword)] . . .
Después de presionar la tecla "Trace", comienza el proceso de formar un certificado raíz autofirmado de la CA implementada. En el primer paso de este proceso, se seleccionan el tipo y los parámetros del par de claves:
Una vez decidido el par de claves para el certificado raíz del centro de certificación creado, procedemos a completar el formulario con información sobre el propietario (falta la primera captura de pantalla).
Tenga en cuenta que la utilidad CAFL63 tiene una cierta "inteligencia" y, por lo tanto, controla no solo la disponibilidad de datos en los campos, sino también la corrección (resaltado en rojo - incorrecto) de completar campos como TIN, PSRN, SNILS, PSRNIP, dirección de correo electrónico, etc.
Después de completar los campos con información sobre el propietario de la CA, se ofrecerá para determinar la configuración del sistema de la CA:
Si no va a trabajar con la criptografía rusa, puede usar el OpenSSL habitual. Para trabajar con la criptografía rusa, debe seleccionar la versión adecuada, una modificación de OpenSSL. Para más detalles, lea README.txt en la distribución descargada. Dado que se planea emitir certificados calificados, también es necesario proporcionar información sobre la certificación de la propia CA y el sistema de protección de la información criptográfica que utiliza (consulte "Requisitos para el formulario de certificado calificado de una clave de verificación de firma electrónica", aprobado por orden del Servicio Federal de Seguridad de Rusia con fecha 27 de diciembre de 2011 No. 795).
Después de completar correctamente todos los campos, una vez más se le ofrecerá verificar su precisión y hacer clic en el botón "Finalizar":
Después de hacer clic en el botón "Finalizar", se creará la base de datos de CA en la que se guardará el certificado raíz de CA, la clave privada, la configuración del sistema y la página de inicio de la utilidad CAFL63 aparecerá nuevamente en la pantalla. Ahora que hemos creado la base de datos de la CA recién creada, hacemos clic en el botón "Abrir DB", seleccionamos el directorio con la base de datos, vamos a la ventana principal de trabajo de la CA y hacemos clic en el botón "Ver CA CA", nos aseguramos de que el certificado raíz que creamos :
El siguiente paso es preparar plantillas / perfiles de aplicación para entidades jurídicas, individuos, empresarios individuales (
Herramientas-> Configuración-> Tipos de certificados-> Nuevo ):
Después de especificar el nombre del nuevo perfil, se propondrá determinar su composición:
La composición del perfil está determinada por el nombre distinguido (nombre distinguido / único del titular del certificado). Cada perfil tiene su propia composición con campos obligatorios (obligatorios) o no. La composición del perfil para personas jurídicas, individuos, empresarios individuales está determinada por los requisitos de la Ley Federal 63 y los "Requisitos para el formulario de certificado calificado de un certificado de clave de verificación de firma electrónica" FSB de Rusia.
Después de preparar los perfiles, la CA está lista para recibir solicitantes y solicitudes de ellos. Como se señaló anteriormente, el solicitante puede venir con o sin una solicitud lista para un certificado.
Si el solicitante vino con una aplicación lista, luego de verificar sus documentos, la aplicación se importa a la base de datos de la CA. Para hacer esto, seleccione la pestaña "Solicitudes de certificados" en la ventana principal de trabajo, haga clic en el botón "Importar solicitud / CSR" y seleccione el archivo con la solicitud. Después de eso, aparecerá una ventana con información sobre la solicitud:
Después de revisar la solicitud y asegurarse de que se complete correctamente, puede hacer clic en el botón "Importar" para ingresarla en la base de datos. Inmediatamente, notamos que cuando intente volver a hacer una solicitud en la base de datos de la CA, se mostrará un mensaje:
Las solicitudes a la base de datos de CA están marcadas (columna "Tipo") como "Configuración regional" creada en el centro de registro de CA o como "Importación" creada por el propio solicitante, y también se registra el momento de recepción de la solicitud en la CA. Esto puede ser útil para resolver situaciones de conflicto. Por lo tanto, al importar una solicitud de certificado, debe indicar quién creó la solicitud (ver captura de pantalla).
La aplicación importada se encuentra en la base de datos de CA y se muestra en la ventana principal en la pestaña "Solicitudes de certificado". Las solicitudes recibidas se encuentran en la etapa de "consideración" (la columna "Estado" de las pestañas "Solicitudes de certificado" y "Archivos de solicitud"). Para cada solicitud recién recibida, se debe tomar una decisión (menú desplegable cuando hace clic con el botón derecho en la solicitud seleccionada):
Cada solicitud debe ser rechazada o aprobada:
Si la solicitud se rechaza, se mueve de la tabla de solicitudes actuales de reqDB a la tabla del archivo de solicitud de reqDBArc y, en consecuencia, desaparece en la pestaña "Solicitudes de certificado" y aparece en la pestaña "Archivo de solicitud".
La solicitud aprobada permanece en la tabla reqDB y en la pestaña "Solicitudes de certificado" hasta que se emite el certificado, y luego también termina en el archivo.
Antes de emitir el certificado, es necesario aclarar con el solicitante para qué fines (por ejemplo, para acceder al portal de Servicios del Estado) se utilizará el certificado (
Herramientas-> Configuración-> Tipos de certificado -> Individual -> Editar -> Uso de clave ):
Para emitir un certificado, debe seleccionar la aplicación aprobada en la pestaña "Solicitud de certificados", hacer clic con el botón derecho y seleccionar "Emitir certificado" en el menú desplegable. En el widget que aparece, deberá seleccionar el perfil al que debe corresponder el perfil de la solicitud / certificado:
Tenga en cuenta que en el proceso de emisión de un certificado, puede aclarar los valores de un campo en particular:
El procedimiento para emitir un certificado en sí mismo (elemento de menú "Emitir un certificado") difiere poco del procedimiento para crear un certificado raíz o emitir una aplicación:
El certificado emitido aparecerá inmediatamente en la pestaña Certificados. En este caso, el certificado en sí cae en la tabla certDBNew de la base de datos de CA y permanece allí hasta que se publique. Un certificado se considera publicado después de exportarse al volcado SQL de nuevos certificados, que se transfiere a un servicio público. La publicación de un certificado lo mueve de la tabla certDBNew a la tabla certDB.
Si hace clic con el botón derecho en la línea seleccionada en la pestaña "Certificados", aparecerá un menú con las siguientes funciones:
Estas funciones le permiten ver tanto el certificado en sí como la solicitud en función de la cual se emitió. También puede exportar el certificado a un archivo o a la unidad flash de un solicitante. ¡La función más importante aquí es la función de revocación de certificados! Existe una característica tan exótica como exportar un certificado a un contenedor seguro PKCS # 12. Se utiliza cuando el solicitante desea recibir dicho contenedor. Para tales solicitantes, se proporciona una función de generación de solicitudes con guardar la clave privada en un archivo (botón "Crear solicitud / CSR" en la pestaña "Solicitudes de certificado").
Entonces, la CA comenzó su vida, emitió el primer certificado. Uno de los objetivos de la CA es la organización del acceso libre a los certificados emitidos. La publicación de certificados generalmente pasa por servicios web. CAFL63 también tiene este servicio:
Para publicar certificados y listas de certificados revocados en un servicio público, la CA los carga previamente en archivos (
Certificados-> Exportar certificados ) o realiza un volcado de SQL de toda la tabla de certificados desde la cual puede crear una base de datos de certificados y cargarlos en ella, y luego hacerlos Volcado de SQL de nuevos certificados desde los cuales se agregarán a la base de datos de servicio público:
La función fundamental de una AC es publicar una lista de certificados revocados, de forma similar a como lo hace el Ministerio del Interior con respecto a los pasaportes vencidos. El certificado puede ser revocado a solicitud del propietario. La razón principal de la revocación es la pérdida de la clave privada o la pérdida de confianza en ella.
Para revocar un certificado, simplemente selecciónelo en la pestaña "Certificados", haga clic con el botón derecho y seleccione el elemento de menú "Revocación de certificado":
El procedimiento de revocación no es diferente del procedimiento de aprobación para una solicitud o la emisión de un certificado. El certificado revocado cae en la tabla cerDBRev de la base de datos de CA y aparece en la pestaña "Certificados revocados".
Queda por considerar la última función de la CA: el lanzamiento de CRL, una lista de certificados revocados. La lista de CRL se forma en la pestaña "Certificados revocados" cuando hace clic en el botón "Crear SOS / CRL". Todo lo que se requiere del administrador es ingresar la contraseña de CA y confirmar su intención de emitir la CRL:
La CRL emitida cae en la tabla crlDB de la base de datos y se muestra en la pestaña CRL / SOS.
Para analizar la CRL antes de colocarla en la base de datos, se escribió el procedimiento parse_crl:
proc parse_crl {crl} { array set ret [list] if { [string range $crl 0 9 ] == "-----BEGIN" } { array set parsed_crl [::pki::_parse_pem $crl "-----BEGIN X509 CRL-----" "-----END X509 CRL-----"] set crl $parsed_crl(data) } ::asn::asnGetSequence crl crl_seq ::asn::asnGetSequence crl_seq crl_base ::asn::asnGetSequence crl_base crl_full ::asn::asnGetObjectIdentifier crl_full ret(signtype) #puts "KEY_TYPE=$ret(signtype)" ::::asn::asnGetSequence crl_base crl_issue set ret(issue) [::pki::x509::_dn_to_string $crl_issue] #puts "ISSUE=$ret(issue)" ::asn::asnGetUTCTime crl_base ret(publishDate) ::asn::asnGetUTCTime crl_base ret(nextDate) #puts "publishDate=$ret(publishDate)" return [array get ret] }
Para ver la CRL o exportarla para su publicación en un servicio público, debe, como siempre, seleccionar la línea deseada, hacer clic con el botón derecho del mouse y seleccionar el elemento de menú apropiado:
Eso es todo, la Autoridad de Certificación está lista.
Descubra cómo ensamblar y conectar OpenSSL con la criptografía rusa
aquí .