Las 26 razones por las que Chrome no confía en la CA española Camerfirma

A partir de la inminente versión 90, Chrome mostrará un error de certificado cuando un usuario intente acceder a cualquier web con un certificado firmado por Camerfirma. Aunque quizás no sea la CA más popular, está muy presente en España en muchas organizaciones públicas, por ejemplo, en la Agencia Tributaria. Si no se soluciona esta “explusión” de Chrome, para la campaña de la renta puede haber problemas de acceso a las web oficiales.

Otros muchos organismos en España (incluso la web de la campaña de vacunación del COVID, vacunacovid.gob.es) dependen del certificado. Pero, ¿qué ha pasado? ¿Por qué Chrome exactamente deja de confiar en esta CA? Microsoft y Mozilla todavía confían, pero desde luego la decisión de Chrome creará un efecto en cadena que muy probablemente haga que sea imposible confiar en nada emitido por esta CA desde los principales sistemas operativos o navegadores.

En otras noticias sobre este asunto, se habla de los fallos cometidos por Camerfirma y su incapacidad para responder y solucionarlos pero, para ser justos, hay que conocer un poco el mundo de los certificados. Lo primero es tener claro que todas las CAs cometen errores: muchos, siempre. Solo hay que darse una vuelta por Bugzilla. El mundo de la criptografía es extremadamente complejo, y el de los certificados… también.

Seguir los requerimientos no es siempre sencillo y, por ello, la organización CA/Forum y muchos investigadores se encargan de velar por un perfecto funcionamiento de las autoridades de certificación y cumplimiento estricto y riguroso de esos estándares, así que suelen estar muy acostumbrados a estos fallos, errores y despistes y toleran en cierta forma los problemas siempre que se revoque a tiempo y corrijan. Es una cuestión de mostrar voluntad y eficiencia en la gestión, más que de ser perfecto.

Los incidentes ocurren a diario y son variados y complejos, pero normalmente las CA reaccionan solucionándolos e incrementando la vigilancia, cosa que mejora día a día el sistema. Pero a veces, se pierde la confianza en una CA porque se traspasa cierto límite relacionado con sus respuestas y reacciones. En el asunto con Camerfirma parece que la clave es que llevan años cometiendo errores, algunos reiteradamente, y que han demostrado ya demasiadas veces que no se puede confiar en los remedios y prácticas resolutivas de esta autoridad de confianza. Especialmente, parece que no les cuadran sus excusas y explicaciones.

La reacción de Chrome demuestra así que la seguridad criptográfica hay que tomársela en serio, y que no aceptará CAs que confiesen que no cuentan con el personal necesario, que desoyen las especificaciones, etc. Estos movimientos son necesarios. Eso sí, con decisiones como esta, Chrome sigue su camino hacia convertirse en una CA de facto. Ya comentamos que las CA tradicionales están perdiendo el control de los certificados. Este podría ser uno de los posibles motivos por los que Chrome tendrá una nueva Root Store.

Las 26 razones

Vamos a describir las razones muy brevemente y por orden de importancia o relevancia (subjetivo). El texto entrecomillado es literal de lo que hemos encontrado en el tracker Bugzilla, que parece regodearse en la fragilidad de las excusas de Camerfirma. Para ser justos, hay que leerlas en su contexto completo y concreto para entenderlas. Pero aun así, lo que se destila por un lado es cierta incapacidad en Camerfirma para la labor encomendada de ser una CA seria y capaz de responder en tiempo y forma… y por otro un importante hartazgo por parte de los que velan para que esto sea así.

• Uno: en 2017 el mundo dejó de confiar en WoSign/StartCom como CA por diferentes razones. Camerfirma seguía teniendo relación con StartCom como vía para validar ciertos certificados, y lo hacía bajo el criterio de “otros métodos” que es la forma más extraña (y la última) de conseguirlo y por tanto, que levanta sospechas. La CA/Forum no quería ni que se usaran esos “otros métodos” (que venían de una especificación anticuada) ni que se pudiera delegar la validación de certificados en StartCom. Camerfirma no rectificó y continuó la relación con StartCom sin dejar claro cómo.
• Dos: no respetaban el estándar CAA. Este registro DNS debe contener qué CAs son las de preferencia para una web. Por ejemplo, no quiero que la CA X emita un certificado para mí jamás… o sólo quiero que la CA Y emita certificados para mi dominio. Camerfirma pensaba que si existía el certificate transparency ya podían eludir el respetar los estándares CAA, porque “iban con prisas y entendieron mal los requerimientos”.
• Tres: las respuestas OCSP (para revocar rápidamente) no cumplían con los estándares.
• Cuatro: se descubrió que los campos Subject Alternative Names de muchos de sus certificados estaban mal. Cuando reportaron a Camerfirma, no obtuvieron respuesta, porque estos reportes “iban a una sola persona” que no respondía. Nunca llegó a solucionar “intencionadamente” certificados de este tipo e incluso después de revocar alguno, Camerfirma volvía a emitirlos mal.
• Cinco: intesa Sanpaolo, una de las sub-CAs de Camerfirma, cometía también varios errores a la hora de revocar a tiempo. Incluso llegó a emitir por “error humano” un certificado para “com.com”.
• Seis: cometieron ciertas revocaciones por error, confundiendo números de serie en certificados válidos y no válidos. En Camerfirma decidieron hacer una “desrevocación”, cosa que es intolerable en el mundo de los certificados, pero lo implementaron de manera inconsistente. En medio de todo el problema, alegaron que usarían el software de gestión EJBCA para mitigar esto en el futuro, pero luego no… luego confirmaron que desarrollarían software propio con similares características. Como no se supo mucho más después sobre esto, alegaron que estaban en “reuniones diarias para discutir estos asuntos”.
• Siete: Camerfirma violaba una regla relacionada con la inclusión del nombre del emisor y el número de serie en el campo key ID (no se debe). Todos los certificados de Camerfirma lo hacían mal desde 2003. Alegaron que lo habían entendido mal y lo arreglaron a finales de 2019. Pero no revocaron los anteriores emitidos. En 2020 volvieron a emitir certificados que violaban esta política, que tampoco revocaron.
• Ocho, nueve y diez: se supone que no deben emitir certificados con guiones bajos en sus nombres. Según un “error humano” en su emisión y detección, no eran capaces de detectarlos a tiempo y algunos se le pasaron. También les ocurrió con un nombre de dominio con el carácter “:”. Y con un dominio que existía pero que deletrearon mal en el certificado.
• Once: Camerfirma (y otras) emitieron sub-CAs que podían dar respuestas OCSP para la propia Camerfirma, porque no habían incluido una restricción adecuada en las EKU del certificado (las EKUs son campos para limitar el poder y uso del certificado). Argumentaron que no tenían conciencia de este fallo de seguridad y no los revocaron a tiempo. La razón para no revocar es que una de las sub-CAs se empleaba en el sector de las smartcards de salud y si los anulaban habría que reemplazar esas tarjetas inteligentes. Tan importante era el problema que debían elevar el problema a órganos superiores de nivel nacional. El dos de octubre de 2020 parece que se destruyeron las claves en estas tarjetas, pero esa destrucción no fue supervisada ni atestiguado por un auditor cualificado ni por la propia Camerfirma.
• Doce: emitieron una subCA para uso en S/MIME para el gobierno de Andorra, que no auditaron. Cuando lo hicieron, se comprobó que cometían bastantes errores. Al final tuvieron que revocarlo, y alegaron que como eran certificados TLS, pensaban que no entraban en el alcance de las auditorías. De nuevo, el problema parecía ser que no disponían del personal suficiente y necesario.
• De trece a veintiséis: hacemos trampa aquí para aglutinar el resto de razones que resultan muy parecidas. Por ejemplo, decenas de fallos técnicos en otros campos de certificados que no eran capaces de revocar a tiempo. Y para ello las excusas eran variadas. Desde que la legislación local les obligaba a ciertas fórmulas que no cumplían los estándares (cosas que no demostraban)… hasta que su sistema había funcionado bien 17 años, pero que luego al crecer mucho, fallaron algunos controles internos. A veces no había ni excusas. Simplemente no contestaban a los requerimientos. En uno de los incidentes, se supone que debían dar a conocer la existencia de una sub-CA máximo una semana después de su creación pero no lo hacían. Lo que ocurría según ellos es que “la persona encargada no estaba disponible”. Tampoco el respaldo de esa persona. Camerfirma lo intentó solucionar diciendo que pondría “un respaldo para la persona de respaldo encargada de esta comunicación”. Para resolver otros problemas, Alegaban que su personal estaba completamente “desbordado”, o “de vacaciones”. Básicamente, de todos los fallos comunes en muchos certificados (insuficiente entropía, extensiones incorrectas…), Camerfirma siempre fallaba al revocar en tiempo y forma en los certificados.

Conclusiones

No es fácil ser una CA. Camerfirma no es la primera ni la última revocada. Hasta Symantec sufrió un revés en este aspecto. También lo pasó muy mal la FMNT para que Firefox incluyera su certificado en su repositorio y necesitó un periplo de varios años. En algunos de los puntos de esa historia increíble con la FMNT se perciben también tiempos muertos, en los que se intuye carecer del personal adecuado para satisfacer las demandas de Mozilla.

Y es que el mundo de los certificados es exigente. Pero es que así debe ser. Del buen hacer de las CA depende, literalmente, el internet que se ha construido. Tolerar el funcionamiento de una CA que se salga un milímetro de una continua vigilancia, control y exigencia o no responda en tiempo y forma, es como permitir la condescendencia ante un policía o un juez que comete cualquier atisbo de corrupción. No debe ser tolerado por nuestro propio bien y por las importantes consecuencias que conllevaría.

Si tienes alguna duda sobre cómo podría afectar este cambio a tu negocio contacta con nosotros.

Más información sobre certificados digitales en este post: