1397969 - DigiCert / Inteso San Paulo: Double dot characters

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

This bug has been separated out from Bug #1389172 to request an incident report specific to this subCA.

Inteso San Paulo
  a) Double dot characters
    - See Bug #1389172: Comments 3, 5, 6, 9
    - Remediation
      - None performed


For the problem listed above, please provide an incident report as described here:

https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 1

[Ben Wilson]

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. 

Email to m.d.s.p. from Jonathan Rudenberg dated 17-July-2017

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

17-July-2017 - Forwarded email to Intesa Sanpaolo; certificates https://crt.sh/?id=98377380&opt=cablint and https://crt.sh/?id=172218371&opt=cablint replaced on 18-July-2017 and revoked on 19-July-2017.  

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

Intesa Sanpaolo to provide

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. 

The two certificates identified on https://misissued.com/batch/13/ are https://crt.sh/?id=98377380&opt=cablint (issued 28-Feb-2017) and https://crt.sh/?id=172218371&opt=cablint (issued 12-Jul-2017)

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. 

See above 

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

It appears that the double decimals were fat-fingered, although I cannot represent that as the actual cause. I also assume that they avoided detection because there was no procedure in place to check them.   Intesa Sanpaolo should provide more information.

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. 

To be provided by Intesa Sanpaolo.  Also, DigiCert will work with Intesa Sanpaolo to come up with a set of actions and a timeline.

Comment 2

[Ben Wilson]

> 3.	Confirmation that your CA has stopped issuing TLS/SSL certificates with
> the problem. 
> 
> Intesa Sanpaolo to provide

[ISP 18-Sep-2017] We can confirm that after your segnalation (17 July 2017) we replaced and revoked the certificate indicated.

> 
> See above 
> 
> 6.	Explanation about how and why the mistakes were made or bugs introduced,
> and how they avoided detection until now. 
> 
> It appears that the double decimals were fat-fingered, although I cannot
> represent that as the actual cause. I also assume that they avoided
> detection because there was no procedure in place to check them.   Intesa
> Sanpaolo should provide more information.

[ISP 18-Sep-2017] We confirm this was a typing error (double dot). We resolved the problem by replacing the wrong certificate.

> 
> 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. 
> 
> To be provided by Intesa Sanpaolo.  Also, DigiCert will work with Intesa
> Sanpaolo to come up with a set of actions and a timeline.

[ISP 18-Sep-2017] We have solved the problem: since 11-Sep-2017 we are no longer releasing SSL certificates with that CA (sub-CA of Digicert), which remains active for SSL certificates already issued by it.

Comment 3

[Ryan Sleevi]

(In reply to Ben Wilson from comment #2)
> [ISP 18-Sep-2017] We have solved the problem: since 11-Sep-2017 we are no
> longer releasing SSL certificates with that CA (sub-CA of Digicert), which
> remains active for SSL certificates already issued by it.

This certificate is not scheduled to expire until 2024.

Given that this sub-CA only remains active for SSL certificate issuance, will this be revoked when the last certificate expires? If so, when is that. If not, why not?

The intent of these questions is to understand the risk to the ecosystem to continue to trust this certificate, and the set of mitigations put in place to prevent future misissuance. While an intent not to issue does represent a good step, the technical capability still exists, and thus the need to ensure these systems are robust and protected similarly exist. Alternatively, working with DigiCert to allow DigiCert to provide OCSP and CRL services (by transferring the key to their control) may also offer some mitigations.

Comment 4

[Ben Wilson]

We are in the process of discussing these options with Intesa Sanpaolo. Nevertheless, they would like this bug closed.

Comment 5

[Gervase Markham [:gerv]]

Ben: any news on the progress of those discussions? Has a way forward been identified?

Gerv

Comment 6

[Ben Wilson]

Attachment: 2016 Innovery Audit of Intesa SanPaolo

Intesa Sanpaolo asserts, "Regarding the audit certificate, we confirm that the CAs complies with the CA/Browser Forum’s baseline requirements. Last year our auditor, Innovery, performed the audit procedure referring to the CA/Browser Forum Baseline (see attachment eu.inn.AuditSSL Intesa SanPaolo v1.0.2.pdf, pages 3 “This Audit procedure is performed under the CA/Browser Forum Baseline Requirements specification, clause 8.4 point 2 (ETSI EN 319 411-1 scheme)  that is therefore based on the same schema (ETSI EN 319 411-1) according to which we have been audited this year by DNV-GL (see page 1 of the attachment DNV - EIDAS Certificate.pdf)."

Comment 7

[Ben Wilson]

Attachment: DNV - EIDAS Certificate.pdf

Intesa Sanpaolo asserts, "regarding the annual audit we’ve already take contact with Innovery, the Company that certified last year our infrastructure. 
As DNV had  previously communicated to us, also Innovery has confirmed that our Eidas Certificate is conformed with the CA Browser forum Baseline. 
Innovery has given us some more public evidence to support our point of view and we would like to share them with you. 

Inside the document “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” at the chapter 8.4 Topic covered by assessment it is clearly specified: 
The CA SHALL undergo an audit in accordance with one of the following schemes:
1. WebTrust for Certification Authorities v2.0;
2. A national scheme that audits conformance to ETSI TS 102 042/ ETSI EN 319 411-1;
etc…

At the same time, inside the ETSI 319 411-1, as well as in the ETSI 319 412-4, specific for the for web site certificates, it’s reported in the Introduction: 
“The present document is aiming to meet the general requirements of the international community to provide trust and confidence in electronic transactions including, amongst others, applicable requirements from Regulation (EU)
No 910/2014 [i.15] and those from CA/Browser Forum, BRG [5 - CA/Browser Forum (V1.3.0): "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates"

The audit report, previously shared with you, show that DNV has executed the audit activities according to the ETSI standard and in compliance with:
ETSI EN 319 401
ETSI EN 319 411-1
ETSI EN 319 411-2
ETSI EN 319 412-1/2/3/4/5

Can you help us to understand the reason why according to you we are not compliance with the Browser Forum Baseline Requirements? 
We would really appreciate you to help us to understand what we are missing to be compliant with the standard."

Comment 8

[Ben Wilson]

Intesa Sanpaolo has indicated that they are proceeding to move to a new CA and from January 1st DigiCert can revoke the certificate. They also wanted me to convey via this post their "assurance" that Intesa Sanpaolo is not issuing new certificates with the CA.

Comment 9

[Gervase Markham [:gerv]]

Ben: I'm not sure why Intesa Sanpaolo are obsessed with proving that they have the right audits. As far as I can see, no-one has called their audit paperwork into question, at least in this bug. But having a BR audit doesn't automatically mean one is always perfectly in compliance with the standard - bugs happen, mistakes happen. 

The issue here is that they issued some certs with two consecutive dots. We first want to know - why? They say it was a typing error. OK - so how is such an error going to be avoided in future? They say they are going to stop using this CA, but do we have any assurance that such an error is not possible with any replacement CA? Are they doing an on-premises replacement or a hosted/managed replacement?

What we want to see is some root cause analysis of the problem, so we can see what has been but in place to prevent it recurring.

Gerv

Comment 10

[Jeremy Rowley]

They are moving to a hosted solution so the error will not occur going forward. We aren't issuing any new or replacement TLS on-prem CAs and actively working to shut down the ones that currently exist.  I'm still not sure the root cause. My guess is the old Verizon software was never patched and signed what was in the CSR if the risk checks passed. Revocation is still scheduled for 1/1/2018.  We trying to get a better understanding of why this happened, but I don't think there's a good answer other than the SANS with double dots was permitted under their issuing system.

Comment 11

[Ben Wilson]

(In reply to Gervase Markham [:gerv] from comment #9)
> Ben: I'm not sure why Intesa Sanpaolo are obsessed with proving that they
> have the right audits. As far as I can see, no-one has called their audit
> paperwork into question, at least in this bug. But having a BR audit doesn't
> automatically mean one is always perfectly in compliance with the standard -
> bugs happen, mistakes happen. 
> 
> The issue here is that they issued some certs with two consecutive dots. We
> first want to know - why? They say it was a typing error. OK - so how is
> such an error going to be avoided in future? They say they are going to stop
> using this CA, but do we have any assurance that such an error is not
> possible with any replacement CA? Are they doing an on-premises replacement
> or a hosted/managed replacement?
> 
> What we want to see is some root cause analysis of the problem, so we can
> see what has been but in place to prevent it recurring.
> 
> Gerv

The issue is that we need sign-off from someone other than DigiCert on the audit paperwork.  I'm not going to upload this document link to the CCADB with the implication that I am asserting that it is compliant.  Right now they are listed on https://crt.sh/mozilla-disclosures as having an outdated audit.  If I upload the link to the 2017 audit, I don't want it later argued by anyone that I was trying to mislead, but if Mozilla doesn't have a problem with it, then I'll put that link into the CCADB.

Comment 12

[Kathleen Wilson]

(In reply to Ben Wilson from comment #11)
> Right now
> they are listed on https://crt.sh/mozilla-disclosures as having an outdated
> audit.  If I upload the link to the 2017 audit, I don't want it later argued
> by anyone that I was trying to mislead, but if Mozilla doesn't have a
> problem with it, then I'll put that link into the CCADB.

Actually, I had noticed that in these CCADB records the fields that were supposed to have the links to the Standard Audit and BR Audit had the text "Available upon request". So these records with that data must have been created before we added the rule in CCADB to require those fields to have an actual URL.

When I deleted the text "Available upon request", the records started showing up in the mozilla-disclosures page.

So, please go ahead and add the correct links to the audit statements, etc.

Comment 13

[Gervase Markham [:gerv]]

(In reply to Jeremy Rowley from comment #10)
> Revocation is
> still scheduled for 1/1/2018.  

Did this happen?

Gerv

Comment 14

[Ben Wilson]

We usually do these every other Tuesday, so it is scheduled to occur on 16-Jan-2018.  We will be revoking the following three serial numbers issued by the Baltimore Cybertrust Root:
0727bdce
0727bdcf
072796c8

Comment 15

[Jeremy Rowley]

We should add to OneCRL now though.

Comment 16

[Kathleen Wilson]

(In reply to Ben Wilson from comment #14)
> We usually do these every other Tuesday, so it is scheduled to occur on
> 16-Jan-2018.  We will be revoking the following three serial numbers issued
> by the Baltimore Cybertrust Root:
> 0727bdce
> 0727bdcf
> 072796c8

Thanks, Ben, for updating their revocation status in the CCADB.

I have updated their OneCRL Status to "Ready to Add", so they will be added to OneCRL via are standard process.

Comment 17

[Wayne Thayer]

These three subordinate CAs have been added to OneCRL. Resolving this bug.