1448986 - Entrust: IP Address in dNSName form

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Bruce Morton]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

Entrust issued an SSL certificate, with an IP Address and CT logged


Actual results:

IP Address was indicated in the dNSName form


Expected results:

IP Address should have been indicated in the iPAddress name form

Comment 1

[Bruce Morton]

1.    How your CA first became aware of the problem

Entrust Datacard first became aware of an invalidly-formed certificate per email on March 22, 2018.
 
2.    A timeline of the actions your CA took in response

Mar 22, 2018 – Received incident notice
Mar 22, 2018 – Started investigation
Mar 23, 2018 - Started testing, looking for other certificates and developing a solution
Mar 23, 2018 - Revoked invalidly formed certificates
Mar 26, 2017 - Implemented bug fix

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

No certificates were issued with this issue from notification of incident to the bug being fixed.

4.    A summary of the problematic certificates

Entrust implemented the option for OV certificates to be CT logged with pre-certificates in October 2016. There was a bug when CT logging was used with a certificate with an IP address in the SAN. There were 2 certificates issued which indicates an IP address in the SAN as a DNS name.

5.    The complete certificate data for the problematic certificates

https://crt.sh/?id=361439186
https://certspotter.com/api/v0/certs?domain=staging.textblue.ca

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

The bug was introduced on October 2016, when an option was added to allow CT logging for OV certificates. The bug affects all OV certificates which used the IP address in the CN and SAN and had opted for CT logging.

The bug avoided detection as there were only 2 certificates issued with this configuration. The 3% self-audit did not detect the issue the first time and there were no browser/server failures. The issue for the second occurrence would have been detected when the weekly review of https://crt.sh/?cablint=1+week was performed.

7.    List of steps your CA is taking to resolve the situation

Entrust has corrected the bug when issuing a certificate which is logged to CT and contains an IP address. This type of bug will be more easily detected in future as Entrust will be implementing self-audit for all SSL certificates with tests including cablint.

Comment 2

[Ryan Sleevi]

(In reply to Bruce Morton from comment #1)
> 1.    How your CA first became aware of the problem
> 
> Entrust Datacard first became aware of an invalidly-formed certificate per
> email on March 22, 2018.

This was noticed externally by looking through crt.sh for errors.

QUESTION: Does Entrust actively monitor external resources for possible misissuance events? Your reply to #6 suggests it's weekly.

> 6.    Explanation about how and why the mistakes were made or bugs
> introduced, and how they avoided detection until now.
> 
> The bug was introduced on October 2016, when an option was added to allow CT
> logging for OV certificates. The bug affects all OV certificates which used
> the IP address in the CN and SAN and had opted for CT logging.

QUESTION: In order for the ecosystem to improve its understanding and handling, it's helpful to provide more detail. Here, you claim that it was related to CT logging - but it's not obvious why that would be. Can you explain more about how it relates?

> The bug avoided detection as there were only 2 certificates issued with this
> configuration. The 3% self-audit did not detect the issue the first time and
> there were no browser/server failures. The issue for the second occurrence
> would have been detected when the weekly review of
> https://crt.sh/?cablint=1+week was performed.
> 
> 7.    List of steps your CA is taking to resolve the situation
> 
> Entrust has corrected the bug when issuing a certificate which is logged to
> CT and contains an IP address. This type of bug will be more easily detected
> in future as Entrust will be implementing self-audit for all SSL
> certificates with tests including cablint.

Can you provide a timeline for when this is?

Comment 3

[Bruce Morton]

Entrust uses external resources to test compliance to BR, EV, and CT for EV. We use cablint for certificates found through CT on a weekly basis. Internal post issuance checks are for defined certificate profiles and Debian weak keys which are performed on all issued certificates. Moving ahead, the goal is to use external resources (including cablint) and other internal tests on an hourly post issuance check for 100% of certificates of all types. We plan to have this check implemented at the end of April 2018. 

Regarding how the bug relates to CT. Parts of the certificate request code are split into CT and non-CT paths. When CT was originally implemented for EV certificates, the CT path did not ensure that an IP address SAN was in the correct iPAddress form, as a SAN in an EV cert would never contain an IP address. When we added CT for OV certificates, the OV cert request now went down the CT path, which did not ensure the IP address SAN was in the correct iPAddress form. This bug has been fixed by a minor code refactor.

Comment 4

[Wayne Thayer]

(In reply to Bruce Morton from comment #3)
> Entrust uses external resources to test compliance to BR, EV, and CT for EV.
> We use cablint for certificates found through CT on a weekly basis. Internal
> post issuance checks are for defined certificate profiles and Debian weak
> keys which are performed on all issued certificates. Moving ahead, the goal
> is to use external resources (including cablint) and other internal tests on
> an hourly post issuance check for 100% of certificates of all types. We plan
> to have this check implemented at the end of April 2018. 
> 
Bruce: Does this mean that Entrust is not planning to implement pre-issuance linting?

Comment 5

[Bruce Morton]

(In reply to Wayne Thayer [:wayne] from comment #4)
> Bruce: Does this mean that Entrust is not planning to implement pre-issuance
> linting?

No. As we move ahead with our post issuance checks, once we have gained confidence in the tests, this test could be moved to prior to certificate release or could be done on pre-certificates before the certificate is issued.

Comment 6

[Wayne Thayer]

Bruce: given that we are strongly encouraging CAs to perform pre-issuance linting, can you provide more specifics about Entrust's plans to implement pre-issuance linting of all certificates? Or are you just saying that Entrust might implement that someday?

Comment 7

[Bruce Morton]

We plan to extend our linting to pre-issuance linting in the first release of 2019. We are still defining our approach and how we will extend to our full line of products, that is, SSL and all non-SSL certificates.

Comment 8

[Wayne Thayer]

Updated bug to request follow-up in 2019 confirming that pre-issuance linting is in place.

Comment 9

[Ryan Sleevi]

To confirm: Is Comment #7 still accurate and on track?

Based on it, it sounds like the approach should be defined by now to achieve that implementation in 2019 - can you provide more details about this, congruent to this report and its root cause?

Comment 10

[Ryan Sleevi]

Bruce: Do you have an update?

Comment 11

[Bruce Morton]

We currently have post-issuance linting in place to cover all public and private trust certificate types including SSL/TLS, code signing, S/MIME, and document signing. We are progressing on pre-issuance linting, but have not yet deployed.

Comment 12

[Ryan Sleevi]

Bruce: Do you have a concrete timeline for pre-issuance linting? Comment #7 said "the first release of 2019", and it's important to understand what that timeframe now looks like.

Comment 13

[Bruce Morton]

Ryan: Pre-issuance linting is not a CAB Forum nor a root embedding program requirement. Perhaps you can provide some information on why the timing of optional implementation by one CA in the ecosystem is important.

Comment 14

[Ryan Sleevi]

When resolving incident reports, we seek to make sure that the CA that caused an incident has investigated root causes and implemented meaningful remediations that provide the community assurance that the incident will not re-occur.

Comment #5, Comment #6, and Comment #7 showed an exchange regarding whether or not the steps taken, thus far, meaningfully prevent the issue. As Comment #8 captured, this incident report was not closed out, on the basis that Entrust would be implementing pre-issuance linting in the "first release of 2019".

If Entrust is now not planning to do what they stated in Comment #7, then I'll defer this to Wayne. I think it'd be concerning for a CA to commit to something and then not deliver, and thus the question remains whether or not Comment #7 is accurate.

Comment 15

[Bruce Morton]

Ryan: Thanks for the response. As stated, Entrust Datacard does plan to implement pre-issuance linting.

Comment 16

[Wayne Thayer]

Bruce: are you willing to provide a new date by which pre-issuance linting will be implemented? This incident is closing in on a year old, and the generous timing that was originally accepted for pre-issuance linting has now passed. Without a date, you are effectively stating that - at least as it relates to this incident - Entrust will not implement pre-issuance linting.

While you are correct that there is no mandate for CAs to do so, future misissuances that would have been prevented by pre-issuance linting will be judged as more severe given Entrust's conscious decision against prevention. Bug #1512018 increases my doubt that the current remediation is effective. While not a violation, the sloppiness highlighted by https://crt.sh/?cablint=923&iCAID=1586&minNotBefore=2019-01-01 is further evidence of the need for pre-issuance linting.

Comment 17

[Bruce Morton]

We plan to implement pre-issuance linting in the first release of 2019, which is planned for release 12.7 in April 2019.

We currently have post-issuance linting using cablint, but are considering moving to zlint. Any suggestions as tests provide different results and we are not sure as to the commitment to management of these tools?

Our plan is to block issuance/CT logging on error and failure conditions, but not on warning conditions.

We currently perform post-issuance checks which will be Entrust specific based on the CA and certificate type. We may add these checks to pre-issuance linting. All post-issuance checks are performed on all certificate types issued including SSL, S/MIME, Code Signing, Document Signing and private trust certificates.

Comment 18

[Bruce Morton]

Pre-issuance linting is still on track and the release is scheduled for 1 May 2019.

Comment 19

[Bruce Morton]

Pre-issuance linting for all public trust SSL certificates has been implemented on 14 May 2019.

Comment 20

[Wayne Thayer]

It appears that remediation has been completed.