Closed Bug 1524876 Opened 3 years ago Closed 3 years ago

Entrust: IP in dnsName


(NSS :: CA Certificate Compliance, task)

Not set


(Not tracked)



(Reporter: jonathan, Assigned: bruce.morton)


(Whiteboard: [ca-compliance])

Entrust issued the following certificates with invalid dnsNames containing IP addresses.

For context, in bug 1448986, Entrust claimed that they "look[ed] for other certificates" with this issue and "there were only 2 certificates issued with this configuration."

I notified them at 2019-01-29 12:51 UTC and they replied with the following message:

We've taken a look at the certificates you brought forward internally and have an answer for you. In August 2016, we modified our issuance policies to correct the dnsName discrepancy however a decision was made at that time to allow existing certificates to expire, rather than be revoked.

The reasoning behind this decision is that the dnsName field containing an IP address was required to ensure support from some browsers, and there was no direct security concern brought forward by this discrepancy.

Currently, that plan has not changed, and we will continue to allow these mentioned certificates to expire in line with our original decision.

It is concerning the disconnect between the comment in Issue 1448986.

Bruce, please provide an incident report regarding these, given that this information conflicts with responses Entrust has previously provided.

Assignee: wthayer → bruce.morton
Ever confirmed: true
Flags: needinfo?(bruce.morton)
QA Contact: kwilson → wthayer
Whiteboard: [ca-compliance]

Ryan, we are investigating.

Please note that there was a bug a few years ago, From this discussion, Entrust patched our issue in August 2016. It was decided that we would not revoke old certificates as they were issued to support the Microsoft issue. We decided to let them expire.

In March 2018, we discovered a miss-issuance (issue 1448986) and investigated the issue back to the time of our August 2016 patch. We discovered 2 certificates were miss-issued after the patch was released. These were discussed with issue 1448986.

Note, we were not trying to provide conflicting information as we did not investigate the issue to certificates issued before the patch. We did not consider these certificates to be miss-issued as they were issued to support the Microsoft browser issue.

Flags: needinfo?(bruce.morton)

Ryan: I also recall a CA/browser Forum discussion on this topic in April 2016, see I cannot find a proper resolution to this discussion. Do you recall?

Thanks, Bruce.

Yes, the result was which provided clear technical guidance for CAs and demonstrated a solution that fully complied with the BRs and RFC 5280 w/o any incompatibilities identified with any software, certainly not any browsers. The ballot never went further, because it was unnecessary.

Investigation is complete. Subscribers are being contacted and revocation process has started. Miss-issue report will be posted in the next few days.

  1. How your CA first became aware of the problem

Entrust Datacard was notified that certificates were issued with the IP address in the SAN as a sNSName on January 29, 2019 with an email from Jonathan Rudenberg.

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

Jan 29, 2019, 12:51 UTC - Email notification
Jan 30, 2019, 21:15 UTC - Email response stating current plan
Feb 3, 2019, 19:19 UTC - Bug 1524876 opened
Feb 4, 2019, 16:52 UTC - Email notification of bug
Feb 4, 2019, 19:57 UTC - Investigation started
Feb 5, 2019 20:34 UTC - All certificates identified

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

Entrust Datacard stopped issuing these certificate in August 2016. We did have a miss-issuance of 2 certificates after August 2016 which has been reported,

  1. A summary of the problematic certificates

Through to August 2016, Entrust Datacard issued certificates with the IP address in the SAN dNSName to support a Microsoft browser issue. This was common in the ecosystem. The issue was discussed by Mozilla, It was also discussed by the CA/Browser Forum and the following was posted, As a result of these discussions, we fixed our issue in August 2016.

Entrust Datacard was unaware that certificates issued in this way should be disclosed or revoked. As such, all certificates allowed to expire.

  1. The complete certificate data for the problematic certificates

The following certificates were provided to Entrust Datacard by Jonathan Rudenberg:

The following certificates were found through the investigation:

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

This mistake was made to address a browser issue before the CA/Browser Forum Baseline requirements were introduced. The implementation of the Baseline Requirements failed to address this issue. The issue was detected through certificate linting and was address through a patch in August 2016.

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

Entrust Datacard patched this issue in August 2016 and uses certificate linting to detect this instance if it occurs again.

All unexpired/unrevoked certificates were revoked on or before February 8, 2019 with the exception of the following certificates:

These certificates are scheduled to be revoked on February 22, 2019.

Whiteboard: [ca-compliance] → [ca-compliance] Next Update - 23-February 2019

We have granted the request of the Subscriber to move the certificate revocation date for the last 4 certificates to 28 February 2019.

Whiteboard: [ca-compliance] Next Update - 23-February 2019 → [ca-compliance] Next Update - 28-February 2019

The remaining 4 certificates were revoked on 28 February 2019.

It appears that remediation is complete.

Closed: 3 years ago
Resolution: --- → FIXED
Whiteboard: [ca-compliance] Next Update - 28-February 2019 → [ca-compliance]
You need to log in before you can comment on or make changes to this bug.