1398240 - Firmaprofesional: Non-BR-Compliant OCSP Responders

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

Problems have been found with OCSP responders for this CA, and reported in the mozilla.dev.security.policy forum here:

https://groups.google.com/d/msg/mozilla.dev.security.policy/o1MX07iWDco/RuM1NK_0AQAJ

As per section 4.9.10 of the BRs, OCSP responders MUST NOT respond with a “good” status for unissued certificates. The effective date for this requirement was 2013-08-01.

Please provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 1

[chemalogo]

1.- How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.

We were aware of the issue the 29th of August via an email from Paul Kehrer via dev-security-policy

2.- A timeline of the actions your CA took in response.

In fact,as far as we see it, it is not a problem. The reported CAs are no longer issuing SSL/EV certificates.
All SSL/EV certificates issued by Firmaprofesional are issued from CA commonName = AC Firmaprofesional - INFRAESTRUCTURA, Serial Number: 3137071291384231299 (0x2b891db7f6087583), whose OCSP responder is working pursuant current Baseline Requirements

3.- Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.

Yes we do confirm that the affected CAs are no longer issuing SSL nor EV certificates.

4.- A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

Last certificate issued by AAPP:
* notBefore:2015-03-25
* commonName: sedeelectronica.unavarra.es
* sn: ‎16 51 68 7a 81 55 a5 b0
* SKI: dc 01 34 fa 47 37 c7 8b ee 72 b4 c8 0e ee 5e 9c 5a f3 79 0e

Last certificate issued by CA1:
* notBefore: 2015-05-19
* commonName: ccfcserverpre.farmacat.org
* sn: ‎5e 56 98 54 52 c1 df 13
* SKI: 17 2c b9 de 28 a5 7e b9 86 34 ad 7c f7 0b 2b b2 8e 00 37 26

5.- The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

These CAs stopped issuing certificates the 2015-05-19.

6.- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

It is not a problem of the CA certificates. We decided the XXXX to group all certificates policies issuing SSL or EV certificates under a common CA (commonName = AC Firmaprofesional - INFRAESTRUCTURA, Serial Number: 3137071291384231299 (0x2b891db7f6087583)), whose OCSP responder is working pursuant current Baseline Requirements 

7.- List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

If we are not wrong, no further steps are needed.
Let us know if you need further details.

Comment 2

[Gervase Markham [:gerv]]

> The reported CAs are no longer issuing SSL/EV certificates.

Are any of the issued certificates still unexpired and valid?

Gerv

Comment 3

[chemalogo]

Attachment: List of still valid SSL or EV certificates issued by CA1 or AA.PP.

Comment 4

[chemalogo]

Yes.

Find attached ssl.sede.vigentes.ca1.aapp.csv (https://bugzilla.mozilla.org/attachment.cgi?id=8910721) with the list of the still valid SSL certificates issued by CA1 and AA.PP.

We have decided to revoke them all during the next seven days, so they would be revoked by next Thursday 28th September.

I'll update this ticket when work is done.

Comment 5

[chemalogo]

All valid SSL certificates issued by CA1 and AA.PP. have been already revoked.

Comment 6

[Ryan Sleevi]

Given that Comment #5 reports all still-valid certificates has been revoked, is it acceptable to add CA1 and AA.PP to OneCRL?

With respect to the proposal in Comment #1 that your unified common CA is BR compliant, and thus requires no further investigation, it's important to understand why these CAs' OCSP responders were not detected as non-conformant, so that the current CA's OCSP responder similarly does not evade detection of issues. Can you explain why these CAs were not configured properly, and what steps are being taken to ensure that the unified CA is configured properly?

Comment 7

[chemalogo]

It was detected. You can find the Auditors Statement here (in Spanish): https://cert.webtrust.org/SealFile?seal=1847&file=pdf

At page two, Auditor's Opinion it states:

"
Opinión del Auditor
En nuestra opinión, para el periodo comprendido entre el 10 de Marzo de 2014 al 9 de Marzo de 2015, las Manifestaciones de los Administradores de Firmaprofesional, en relación con sus Prácticas como Autoridad de Certificación, están adecuadamente formuladas, en todos sus aspectos significativos basándonos en los criterios del programa Webtrust para Autoridades de Certificación – Criterio de Auditoría de Validación Extendida con la salvedad de las respuestas del OCSP a los certificados no emitidos y que será subsanado acorde al calendario de cambios establecido por la entidad.
"

Translated into English:
"
Auditor's Opinion
In our opinion, for the period from March 10, 2014 to March 9, 2015, the Manifestations of the Directors of Professional Firm, in relation to their Practices as Certification Authority, are adequately formulated, in all their significant aspects based on in the criteria of the Webtrust Program for Certification Authorities - Extended Validation Audit Criteria with the exception of the OCSP responses to certificates not issued and that will be corrected according to the schedule of changes established by the entity.
"

It happened since our then technology sticked to the RFC6960, which allows, (does not requires) to respond with "revoked" for non-issued certificates.

The current technology we are using, the EJBCA VA module, is configured to respond with "revoked" for non-issued certificates.

There are two ways to check that the commonName = AC Firmaprofesional - INFRAESTRUCTURA:
1.- you can test it with a non-issued certificate serial number. 
2.- the recent POSITIVE Audit Report on eIDAS qualified certificates for website authentication updated in the CCADB (pending to upload sworn translation from Spanish into English.

Comment 8

[Gervase Markham [:gerv]]

(In reply to chemalogo from comment #7)
> It was detected. You can find the Auditors Statement here (in Spanish):
> https://cert.webtrust.org/SealFile?seal=1847&file=pdf

Then why, when you were asked "How your CA first became aware of the problem", did you reply: "We were aware of the issue the 29th of August via an email from Paul Kehrer via dev-security-policy"? That seems incorrect if you knew about the issue back in 2015.

RFC 6960 is not the only document binding on your CA. And you don't get to pick and choose which docs you pay attention to. The Baseline Requirements, via the requirement in Mozilla's Root Store Policy, is also binding on you. Given that, why was this issue not remediated when it was first discovered?

Gerv

Comment 9

[chemalogo]

(In reply to Gervase Markham [:gerv] from comment #8)
> (In reply to chemalogo from comment #7)
> > It was detected. You can find the Auditors Statement here (in Spanish):
> > https://cert.webtrust.org/SealFile?seal=1847&file=pdf
> 
> Then why, when you were asked "How your CA first became aware of the
> problem", did you reply: "We were aware of the issue the 29th of August via
> an email from Paul Kehrer via dev-security-policy"? That seems incorrect if
> you knew about the issue back in 2015.

We were aware of this problem *with the new CA* the 29th of August.
> 
> RFC 6960 is not the only document binding on your CA. And you don't get to
> pick and choose which docs you pay attention to. 
I agree. I was stating to which documents our service was bound. I'm not suggesting at all that we get to pick and choose which docs you pay attention to. 

If we are having this discussion is precisely because we are committed to Mozilla and the rest of browsers manufacturers requirements and also with eIDAS REGULATION requeriments.

> The Baseline Requirements,
> via the requirement in Mozilla's Root Store Policy, is also binding on you.
> Given that, why was this issue not remediated when it was first discovered?

Since we eventually obtained the seal and the RFC requirements were fulfilled we treated this as a low level non-conformity. Obviously we were wrong and this is why:
* we already offer an OCSP services according with your requirements.
* we already feed CT Logs, in advance to when it is required.
* we've implemented more automated tests such as CAA pre validation and certlink profile validation

> 
> Gerv

Chema

Comment 10

[Wayne Thayer]

Repoening because the AC "Firmaprofesional - INFRAESTRUCTURA" described in comment 1 as being compliant is listed in the following report as returning "good" for a non-existent certificate: https://crt.sh/ocsp-responders?randomserial=Good&trustedBy=Mozilla&trustedFor=Server%20Authentication&trustedExclude=constrained,expired,onecrl&randomserial=Good&sort=2&dir=v

The "Autoridad de Certificacion Firmaprofesional CIF A62634068" is also listed in the report.

Please provide an explanation for why these are exceptions, or file a new incident report if this is a new error.

Comment 11

[chemalogo]

(In reply to Wayne Thayer [:wayne] from comment #10)
> Repoening because the AC "Firmaprofesional - INFRAESTRUCTURA" described in
> comment 1 as being compliant is listed in the following report as returning
> "good" for a non-existent certificate:
> https://crt.sh/ocsp-
> responders?randomserial=Good&trustedBy=Mozilla&trustedFor=Server%20Authentica
> tion&trustedExclude=constrained,expired,onecrl&randomserial=Good&sort=2&dir=v
> 
> The "Autoridad de Certificacion Firmaprofesional CIF A62634068" is also
> listed in the report.
> 
> Please provide an explanation for why these are exceptions, or file a new
> incident report if this is a new error.

Regarding "Firmaprofesional - INFRAESTRUCTURA" is not an exception. We have a backup system that, if there is not access to the database or the database is not responding, then the OCSPResponse is based on the last CRL issued, so the Relying parties have always access to Certificate Status information. And this is what happened this time. The service is already working properly.

Regarding "Autoridad de Certificacion Firmaprofesional CIF A62634068", We were not aware that this requirement is also applying to root certificates, and we were aware a few weeks ago when the same issue arose in a client, so we planned to implement it to our CA root, too. We are going to deploy this functionality next 22th April, if it is ok for you.

Comment 12

[Wayne Thayer]

(In reply to chemalogo from comment #11)
> Regarding "Firmaprofesional - INFRAESTRUCTURA" is not an exception. We have
> a backup system that, if there is not access to the database or the database
> is not responding, then the OCSPResponse is based on the last CRL issued, so
> the Relying parties have always access to Certificate Status information.
> And this is what happened this time. The service is already working properly.
> 
The report I referenced in comment #10 continues to list "AC Firmaprofesional - INFRAESTRUCTURA" Are you suggesting that the report is incorrect?

Comment 13

[chemalogo]

(In reply to Wayne Thayer [:wayne] from comment #12)
> (In reply to chemalogo from comment #11)
> > Regarding "Firmaprofesional - INFRAESTRUCTURA" is not an exception. We have
> > a backup system that, if there is not access to the database or the database
> > is not responding, then the OCSPResponse is based on the last CRL issued, so
> > the Relying parties have always access to Certificate Status information.
> > And this is what happened this time. The service is already working properly.
> > 
> The report I referenced in comment #10 continues to list "AC
> Firmaprofesional - INFRAESTRUCTURA" Are you suggesting that the report is
> incorrect?

No. It is not incorrect. Our fault: we fixed it but again, started the backup system.

We've fixed it again and tested everything is stable. And we will improve the monitoring system.

Apologies.

Comment 14

[Wayne Thayer]

The report still shows 3 CAs out of compliance:

- "Autoridad de Certificacion Firmaprofesional CIF A62634068" will be fixed on 22-APril according to comment 11
- The other two - AA.PP and CA1 - are no longer issuing certificates according to comment 5. Can these be added to OneCRL as suggested in comment 6?

Comment 15

[chemalogo]

(In reply to Wayne Thayer [:wayne] from comment #14)
> The report still shows 3 CAs out of compliance:
> 
> - "Autoridad de Certificacion Firmaprofesional CIF A62634068" will be fixed
> on 22-APril according to comment 11
In fact, the 20th, Friday. The previous date was a mistake.

> - The other two - AA.PP and CA1 - are no longer issuing certificates
> according to comment 5. Can these be added to OneCRL as suggested in comment
> 6?
Both AA.PP and CA1 do not issue SSL certificates and there are no valid SSL certificates bound to them. In fact CA1 does not issue any public trusted certificate any more and there are no valid certificates so, YES, please, add it to One CRL.

On the other hand, AA.PP. still issues Natural Person certificates that can be use to sign emails. Our concern is that if we add it to One CRL, are these certificates going to be valid to use with products such as Thunderbird? Before adding this CA to OneCRL, could you be so kind to clarify this point?

According to ACTION 1 of the November 2017 CA Communication, this CA is audited. ETSI audit pursuant European regulation eIDAS are available in CCADB.

Comment 16

[Wayne Thayer]

(In reply to chemalogo from comment #15)
> (In reply to Wayne Thayer [:wayne] from comment #14)
> > The report still shows 3 CAs out of compliance:
> > 
> > - "Autoridad de Certificacion Firmaprofesional CIF A62634068" will be fixed
> > on 22-APril according to comment 11
> In fact, the 20th, Friday. The previous date was a mistake.
> 
> > - The other two - AA.PP and CA1 - are no longer issuing certificates
> > according to comment 5. Can these be added to OneCRL as suggested in comment
> > 6?
> Both AA.PP and CA1 do not issue SSL certificates and there are no valid SSL
> certificates bound to them. In fact CA1 does not issue any public trusted
> certificate any more and there are no valid certificates so, YES, please,
> add it to One CRL.
> 
Please submit a bug similar to 1450805 requesting that AA.PP and CA1 be added to OneCRL.

> On the other hand, AA.PP. still issues Natural Person certificates that can
> be use to sign emails. Our concern is that if we add it to One CRL, are
> these certificates going to be valid to use with products such as
> Thunderbird? Before adding this CA to OneCRL, could you be so kind to
> clarify this point?
> 
> According to ACTION 1 of the November 2017 CA Communication, this CA is
> audited. ETSI audit pursuant European regulation eIDAS are available in
> CCADB.

Comment 17

[chemalogo]

(In reply to Wayne Thayer [:wayne] from comment #16)

> Please submit a bug similar to 1450805 requesting that AA.PP and CA1 be
> added to OneCRL.

Done!
https://bugzilla.mozilla.org/show_bug.cgi?id=1455053

Comment 18

[Wayne Thayer]

The non compliant CA certificates have been added to OneCRL. Marking this resolved.