Closed Bug 1391055 Opened 2 years ago Closed 2 years ago

Microsec e-Szigno: Non-BR-Compliant Certificate Issuance

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kwilson, Assigned: szoke.sandor)

References

Details

(Whiteboard: [ca-compliance])

The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience.

To continue inclusion of your CA’s root certificates in Mozilla’s Root Store, you must respond in this bug to provide the following information:
1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.
6) 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.
7) Regular updates to confirm when those steps have been completed.

Note Section 4.9.1.1 of the CA/Browser Forum’s Baseline Requirements, which states:
“The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: …
9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement; 
10. The CA determines that any of the information appearing in the Certificate is inaccurate or misleading; …
14. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 
15. The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).

However, it is not our intent to introduce additional problems by forcing the immediate revocation of certificates that are not BR compliant when they do not pose an urgent security concern. Therefore, we request that your CA perform careful analysis of the situation. If there is justification to not revoke the problematic certificates, then explain those reasons and provide a timeline for when the bulks of the certificates will expire or be revoked/replaced. 

We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement.

We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.


The problems reported for your CA in the mozilla.dev.security.policy forum are as follows:

** Failure to respond within 24 hours after Problem Report submitted
https://groups.google.com/d/msg/mozilla.dev.security.policy/PrsDfS8AMEk/w2AMK81jAQAJ
The problems were reported via your CA’s Problem Reporting Mechanism as listed here:
https://ccadb-public.secure.force.com/mozilla/CAInformationReport
Therefore, if this is the first time you have received notice of the problem(s) listed below, please review and fix your CA’s Problem Reporting Mechanism to ensure that it will work the next time someone reports a problem like this.

** Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

** Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ
The bug refers to two independent problems, I will answer them separately.
** Invalid dnsNames (e.g. invalid characters, internal names, and wildcards in the wrong position)
https://groups.google.com/d/msg/mozilla.dev.security.policy/CfyeeybBz9c/lmmUT4x2CAAJ
https://groups.google.com/d/msg/mozilla.dev.security.policy/D0poUHqiYMw/Pf5p0kB7CAAJ

The main data regarding this problem report

Subject:               www.mokk.hu
problem reported at:   2017.08.08. 03:09
problem reported by:   Jonathan Rudenberg <jonathan@titanous.com>
problem reported to:   info@microsec.hu
internal Bug:          144399  /  2017-08-08 09:46:33
old certificate
serial:                01 f4 fd 34 c2 a2 42 8a c9 c1 74 3c 90 0a
issued:                2017.05.26. 16:12:06
valid:                 2019.05.26. 16:12:06
revoked:               2017.08.10. 14:22:40
new certificate
serial:                02 08 3c a3 92 01 0d 92 22 5c 75 36 50 0a
issued:                2017.08.09. 02:00:00                                                                                                     
valid:                 2019.05.26. 16:12:06

Our answers to your points:

1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
This problem was reported to us by using our standard Problem Reporting channels at info@microsec.hu. We got an e-mail from Jonathan Rudenberg at 2017.08.08. 03:09.
Our customer service registered the Problem Report in our internal Bugzilla at 2017-08-08 09:46:33.
We processed the request and we could find that the problem was caused by the wrong encoding of the Hungarian characters in the SAN field. 
We decided to issue a new certificate and revoke the faulty certificate.
We converted the domain names into punycode and issued a test certificate in our test system at 2017-08-08 13:05:39 CEST.
We contacted our customer and informed him about the problem. He asked a 1 week deadline for the replacement of the certificate in his systems.
We issued the new certificate at 2017.08.09. 02:00:00.
The customer informed us that he could successfully install the new certificate.
We revoked the faulty certificate at 2017.08.10. 14:22:40.

I personally sent an e-mail answer for the Problem Report to Jonathan Rudenberg at 2017-08-08 16:50.

2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
This was an individual problem. Other certificates containing Hungarian characters were issued properly.

We will set up further security measures to avoid the issuance of certificates with this problem. 

3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
We checked all of our valid certificates by using your test tools. This was the only certificate with this problem.

4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
It was the only faulty certificate, it was issued at 2017.05.26. 16:12:06.

5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.
Presently our CA program does not check the encoding of the SAN field. 
It was an individual human mistake, the Hungarian domain names were copied into the CA certificate request form page by using faulty encoding. 
The certificate did not cause any problem at the customer so this problem hasn't been reported to us earlier.

6) 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.
We will set up further security measures to avoid the issuance of certificates with this problem. 
- We will develop an automatic filter into our CA program to detect the faulty encoding of SAN field. The deadline is 2017-09-15.
- We will use your test tools to check each issued SSL certificates in the future. The check will be run manually from next week and later we may develop an automatic test.

7) Regular updates to confirm when those steps have been completed.
I will inform you about the progress of the planned developments.
** Common Name not in SAN
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/4oVzlN1xBgAJ

Subject:                www.fk.hu
problem reported:       2017.08.06. 11:27 Erdősi Péter Máté [mailto:epm@idoertek.eu] (auditor)
problem reported to:    Dr. Szőke Sándor <szoke.sandor@microsec.hu>
internal Bug:           144396  /  2017-08-08 09:37:10
old certificate
serial:                 01 d6 f2 8b 19 24 06 24 33 49 86 d9 3f 0a
issued:                 2016.12.16. 15:40:26
valid:                  2018.12.16. 15:40:26
revoked:                2017.08.16. 08:53:20
new certificate
serial:                 02 08 27 06 76 ad 8e bf 33 b5 a9 63 db 0a
issued:                 2017.08.08. 02:00:00                      
valid:                  2018.12.16. 15:40:26


1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
I got an encrypted e-mail from one of our auditors to my personal e-mail address on Sunday at 2017.08.06. 11:27.
I was on holiday and I couldn't read the encrypted e-mail on my mobile phone so I asked Peter to send me his message in an open form. I got the open message at 2017.08.07. 10:44.
I was back in the office on Tuesday morning and I registered the Problem Report in our Bugzilla system at 2017-08-08 09:37:10.
We checked the reported certificate and could find a very special problem:
- The Organization Identifier value - which is requested by the eIDAS - was written into a wrong field, into a second Common Name.
We decided to issue a new certificate and revoke the faulty certificate.
We contacted the customer and informed him about the problem. He asked a 1 week deadline for the replacement of the certificate in his systems. 
We issued the new certificate at 2017.08.08. 02:00:00.
The faulty certificate was revoked at 2017.08.16. 08:53:20.

2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
It was a very special problem, so it should not happen again. 
We will develop further security measures to avoid this problem happen again.

3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
We checked all of our valid certificates by using your test tools. This was the only certificate with this problem.

4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.
It was the only faulty certificate, it was issued at 2016.12.16. 15:40:26.

5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.
It was a very special problem. 
It was an individual human mistake, the operator selected a wrong field on the CA certificate request form page for the Organization Identifier value. 
The certificate did not cause any problem at the customer so this problem hasn't been reported to us earlier.

6) 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.
We will set up further security measures to reduce the risk of the issuance of certificates with this or similar problems. 
We will develop an automatic filter into our CA program to detect, if
- there is more than one Common Name in the Certificate request
- the Common Name is not included in the SAN field
In case of any problem the certificate request will be rejected and the certificate will not be issued. 
The deadline of this development is 2017-09-15.
We will use your test tools to check each issued SSL certificates in the future. The check will be run manually from next week and later we may develop an automatic test.

7) Regular updates to confirm when those steps have been completed.
I will inform you about the progress of the planned developments.
Thanks for sharing the details. Out of the CA responses so far, excluding those who responded on list, I think this is the most appropriate and detailed response we've seen.

It's a positive step to see both manual evaluation of the certificates issued, and potentially automated evaluation. If I may suggest, you can also consider running over the tbsCertificates your system plans to sign, before they're signed. If you wrap the tbsCertificate with an invalid signature, but correct signature algorithm (e.g. a signature of all zeroes, but a signatureAlgorithm as appropriate to what you plan to issue), you can detect these issues before you issue certificates. This will help defense in depth.
(In reply to Ryan Sleevi from comment #4)
...  If I may suggest, you can also
> consider running over the tbsCertificates your system plans to sign, before
> they're signed. If you wrap the tbsCertificate with an invalid signature,
> but correct signature algorithm (e.g. a signature of all zeroes, but a
> signatureAlgorithm as appropriate to what you plan to issue), you can detect
> these issues before you issue certificates. This will help defense in depth.


Thanks for your suggestion, we will check this possibility.

The best would be really to find any fault before the issuance of the certificate.


At the same time I inform you that we could successfully install a filter in our CA software which checks the characters in the SAN in the certificate request. Due to this development the CA software will not issue the requested certificate if it contains invalid characters (like special Hungarian characters) in the SAN.
After the reported faulty certificates we decided to check all of our presently valid SSL certificates by using your cablint program.

We could find a very few certificates with some individual problem, most of them has already been replaced and the rest will be replaced by the end of September 2017.


We have a bigger issue what I would like to discuss with you.

Due to a Hungarian technical recommendation (still valid) we issued SSL certificates where all of the following Key Usage bits were set:
"digitalSignature", "keyEncipherment", "keyAgreement".

We changed our Policy on the 2016-10-30 and from that date we issue the SSL certificates only with the following Key Usage bits:
"digitalSignature", "keyEncipherment"

When we went through our valid certificates with your cablint program we got the following error message for several certificates:
E: Unallowed key usage for RSA public key

We think that this error mesage was generated because of the usage of the "KeyAgreement" bit.


We have made a list about our faulty certificates and here are the summarized results:
The number of presently valid certificates with this problem: 178
The last issuance of certificate with this problem:  	      2016-09-05 00:00:00
The expiry of the last certificate with this problem:         2018-09-05 23:59:59

I don't know how big is this problem for the browsers. Our customers hasn't reported any problem to us regarding these certificates.

If they don't cause big problem for the browsers we would like to let these certificates expiry and replace them during the normal renewal process. This means that this problem will be solved within one year.

Is this solution acceptable for you?
For the record, this use of an unallowed key usage is a violation of https://tools.ietf.org/html/rfc3279#section-2.3.1, which lists the permitted key usages for RSA keys.

Gerv
(In reply to dr. Sándor SZŐKE from comment #6)
> If they don't cause big problem for the browsers we would like to let these
> certificates expiry and replace them during the normal renewal process. This
> means that this problem will be solved within one year.
> 
> Is this solution acceptable for you?

Our general principle is that we require prompt revocation and replacement of non-compliant certificates. Please actively replace them. https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Revocation does not mandate a timeline, but letting them expire is not acceptable in this case.

Gerv
OK, we will replace all the non-compliant certificates having "KeyAgreement" bit set. 

The deadline for the replacement is the end of November 2017.

Is it OK?

Sándor
I'm happy to inform you that we revoked all of the misissued certificates with keyAgreement extension set.

Sándor
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.