A raíz de un hilo en Twitter sobre la inexistencia del servicio de CRL de la Autoridad de Certificación de la FNMT sólo se me ha ocurrido que en vez de dedicarme a mis responsabilidades me era imperioso saber qué se estaba cociendo... La noticia más chocante es la actividad reciente en la infame entrada #435736 del bugzilla de Mozilla (abierta desde 2008 para que Mozilla acepte el certificado raiz de la AC FNMT). Parece que por fin alguien se está aplicando a resolver el problema. Y entre las perlas más suculentas allí recogidas está un documento titulado General Certification Practices Statement en el que aparecen detalles como, precisamente, las URIs de publicación de los CRL o los varios servicios OCSP aparentemente disponibles. Si eres de los que han estudiado anteriormente el uso de CERES-FNMT probablemente hayas levantado una ceja. Sí: parece que están habilitando por fin estos servicios. El que no conozca la causa de nuestra sorpresa deberá saber que hasta ahora el servicio de validación de certificados de CERES FNMT para certificados de usuario final (por ejemplo de ciudadanos corrientes y molientes) ha sido de pago (ver ilustración). Para algunos esta ha sido otra de las causas que han lastrado la adopción de la firma digital en España.

Entre los detalles me han llamado la atención las URIs de los servicios OCSP:

• ROOT AC. Access: http://ocspfnmtrcmca.cert.fnmt.es/ocspfnmtrcmca/OcspResponder
• Public Administration AC Subordinate Certificate. Access: http://ocspap.cert.fnmt.es/ocspap/OcspResponder
• Computer Components AC Subordinate Certificate. Access: http://ocspcomp.cert.fnmt.es/ocsp/OcspResponder

y claro, inmediatamente he querido verificar si ya estaban operativos, con la triste circunstancia de que no tengo ni idea de cómo hacerlo. Tras algo de investigación y con oportunismo de corta y pega he dado con una orden que creo serviría:

openssl ocsp -issuer AC_Raiz_FNMT-RCM_SHA256.cer -serial 0x36f11b19 -url http://ocspfnmtrcmca.cert.fnmt.es/ocspfnmtrcmca/OcspResponder -CAfile AC_Raiz_FNMT-RCM_SHA256.cer 

• -issuer AC_Raiz_FNMT-RCM_SHA256.cer el certificado raiz de la AC en cuestión;
• -serial 0x36f11b19 el número de serie de un certificado FNMT emitido en 2005 y caducadísimo;
• -url http://ocspfnmtrcmca.cert.fnmt.es/ocspfnmtrcmca/OcspResponder la URI del servicio OCSP que usaremos, en este caso he elegido el que arriba aparece denominado «ROOT AC. Access» porque me ha parecido el más general para el servicio de particulares comparado con los otros dos;
• -CAfile AC_Raiz_FNMT-RCM_SHA256.cer realmente no sé porqué habría de usar este parámetro, entiendo que es para verificar el resultado ofrecido por el servicio OCSP y todos los ejemplos que he encontrado lo usan de alguna forma; curiosamente sólo he conseguido eliminar los mensajes de error usando el mismo certificado que en -issuer pero no sé si es el comportamiento correcto o si en este caso funciona así por ser un certificado raiz autofirmado.

El resultado obtenido es el siguiente:

Response verify OK
0x36f11b19: good
    This Update: Nov 18 12:11:20 2014 GMT
    Next Update: May 17 11:11:20 2015 GMT

Y podréis decir «pues qué bien, ¿no?». O no. No lo sé. Ignoro los intríngulis de protocolo OCSP pero me esperaba  otra respuesta para un certificado caducado hace más de ocho años. El  caso es el que servicio sí está levantado y podemos ver más detalles usando la opción -text de openssl oscp:

OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = ES, O = FNMT-RCM, OU = AC RAIZ FNMT-RCM, CN = SERVIDOR OCSP AC RAIZ FNMT-RCM
    Produced At: Feb 18 16:27:29 2015 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: BADF8AE3F7EB508C94C1BAE31E7CDC3A713D4437
      Issuer Key Hash: F77DC5FDC4E89A1B7764A7F51DA0CCBF87609A6D
      Serial Number: 36F11B19
    Cert Status: good
    This Update: Nov 18 12:11:20 2014 GMT
    Next Update: May 17 11:11:20 2015 GMT

El caso es que he probado a usar variantes del número serie aleatorias así como de certificados en vigor y siempre da un «good» por respuesta. Y lo poco que me ha podido contar alguien más familiarizado con la tecnología de AC es que este tipo de comportamiento en un servicio OCSP sería normal.

Dudas:

• El servicio OCSP de FNMT, o al menos el que he usado, está levantado, sí, pero ¿ya está realmente operativo?
• ¿Es correcta mi manera de invocarlo desde openssl? no estoy seguro;

Otras conclusiones:

Diría que efectivamente parece FNMT se ha tomado en serio configurarse como una autoridad de certificación seria. Por fin. Supongo que ha podido la presión de al menos los usuarios corporativos públicos que últimamente están emitiendo sus certifcados X509 de servidor a través de Camerfirma (verbigracia la Agencia Tributaria), supongo que cansados de que los usuarios menos avezados se hagan un lío con el proceso de instalación del certificado raiz adecuado y de no saber interpretar correctamente los mensajes de precaución de los navegadores. También parece que empiezan a dejar de usar el nombre Ceres para referirse al servicio. Al menos ha sido mi impresión.

Si alguien detecta errores en lo aquí mostrado estaré encantado de corregir lo que haga falta.

Desde AllTrials.net informan de los avances en la campaña para que la Unión Europea regule la transparencia de los resultados de todos los ensayos clínicos que se realicen a la hora de estudiar posibles nuevas medicinas.

Para el siguiente paso nos solicitan dirigirnos a nuestros eurodiputados para hacerles llegar una carta pidiéndoles el voto a favor del llamado informe Willmott en una votación que tendrá lugar el próximo 3 de abril. Me he tomado la libertad de traducirla a español y ponerla a disposición de todos los interesados:

La idea es enviar una copia de esta carta a nuestros europarlamentarios. También tenéis disponible el enlace a las páginas de su perfiles en la web del Parlamento Europeo, que a su vez contienen al menos el correo electrónico, en un único fichero pdf.

Desde aquí sólo puedo animaros a apoyar este extraordinario ejercicio de transparencia dirigiéndoos a vuestros parlamentarios.

My SSL/TLS certificate has expired so I need to request a new one and I'm summing here all the process.

As my current configuration is more or less a mess, I'm starting from the very begining but I assume you are registered at CAcert.org and you are able to request server certificates for your verified domains. I'll use my tormento.olea.org server as the hostname example.

Note: I found the genkey tool (from the crypto-utils package) takes a lot of more time to generate a same key lenght. Probably due to some kind design goal. I think you could use genkey to generate the key and the csr script for the multi-dns CSR request.

Then I move files to correct systems places:

You can check the certificate is correct using openssl. And you'll receive an email from CAcert reporting about the new certificate.

applications:

These are the applications I've configured for my needs. You have other configuration examples at CAcert website.

postfix

ejabberd

dovecot

apache

Common things you would need to do with your certificates and keys:

Export public key:

Print human readable key data:

Print human readable certificate contents:

Other info of interest

I've not studied it yet but probably it's worth to read the Fedora developments on managing system crypto keys and signatures:

• Shared System Certificates features
• Shared System Certificates followup thread at devel@fedora