1398251 - Staat der Nederlandend / PKIoverheid: 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


Note that the problem has been fixed as of 2017-08-31, so the purpose of this bug is to record the CA's incident report.

Comment 1

[Mark Janssen]

Hi Kathleen,

Seeing that this isn’t a case of mississuance of a (end-user) certificate, several topics listed on the wiki page are not applicable in this case.  Part of my response has already been posted in the MDSP.

Timeline of OCSP incident KPN BV (PKIoverheid/Government of the Netherlands)

Unless otherwise noted, all times are in UTC.

08/29/17 13:41 Paul Kehrer posts in MSDP regarding violation of BR section 4.9.10 by multiple CAs, among them KPN BV (subCA of PKIoverheid / Government of the Netherlands)

08/29/2017 18:28 PA PKIoverheid received notification of possible violation of BR section 4.9.10, Mark Janssen (Policy Authority PKIoverheid) confirmed receipt in MDSP

08/29/2017 18:33 PA PKIoverheid contacts KPN about this issue and asks clarification. 

08/29/2017 19:02 KPN confirms receipt of email and will start an investigation ASAP.

08/30/2017 15:21 KPN confirms that this issue only applies to the OCSP responder in question (ocsp2.managedpki.com) and that certicates issued by KPN over the past few years have been using a different OCSP responder (ocsp3) which is compliant with BR 4.9.10. 

08/31/2017 11:00 KPN confirms that ocsp2 has been fixed and shouldn’t return “Good” to an OCSP query with a unknown serial number / certificate

09/01/2017  11:10 KPN has found the root cause (see below)

09/01/2017 15:08 PA PKIoverheid (Mark Janssen) posts in MDSP detailing the cause of the incident and reporting that the issue has been fixed on 08/31/2017, also outlining which measures PKIoverheid plans to take to prevent future cases like this. 

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. 

See timeline at 08/29/2017 18:28

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

See timeline above

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

N/A

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. 

N/A

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. 

N/A

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

KPN reports that they switched to another OCSP responder (OCSP3) when BR requirement 4.9.10 became effective Around the time KPN deployed a software update regarding OCSP2 which was necessary so this responder would also comply with BR requirement 4.9.10. Although the software upgrade took place, the configuration change to the OCSP2 responder was somehow never executed. Nevertheless, all TLS certificates issued after 10/25/2013 should be directing users to OCSP3. That responder was and is compliant with BR 4.9.10 from the effective date.

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. 

The PA PKIoverheid published a new requirement for our PKIoverheid TSPs regarding audit criteria and scoping. See bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1391864 Result of this new requirement should be that ALL BR requirements are in scope of the audit including a technical requirement like BR 4.9.10.     

Furthermore, we have formulated a plan to prevent future issues like these, which involves active monitoring of the OCSP responses. Not only because of uptime requirements (that was already monitored), but also input/output validation to confirm OCSP responders are behaving like it should. Said mechanism would probably take the form of a fixed interval query which results would be reported by email to us and (possibly) the sub CA from the PKIoverheid TSP in question. This new measure will be effective no later than 10/1/2017. 


Best regards,
Mark Janssen

Comment 2

[Ryan Sleevi]

(In reply to Mark Janssen from comment #1)
> Furthermore, we have formulated a plan to prevent future issues like these,
> which involves active monitoring of the OCSP responses. Not only because of
> uptime requirements (that was already monitored), but also input/output
> validation to confirm OCSP responders are behaving like it should. Said
> mechanism would probably take the form of a fixed interval query which
> results would be reported by email to us and (possibly) the sub CA from the
> PKIoverheid TSP in question. This new measure will be effective no later
> than 10/1/2017. 

Hi Mark,

Can you confirm this was deployed?

Comment 3

[Mark Janssen]

Hi Ryan,

Thanks for the reminder and my apologies for my delayed response. 

Yes, I can confirm that we have implemented the above mentioned mechanism. For now it seems that everything is in order. 

Thanks. 

Best Regards,
Mark Janssen