Re: CA Communication: Underscores in dNSNames
On Thu, Dec 6, 2018 at 10:36 PM pilgrim2223--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I need some clarification on something here
>
> 1) Why are legacy certs not being allowed to expire, and instead we are
> being forced to replace in a very short window? We stopped issuing certs
> with underscores as soon as our CA told us to (probably mid-September) but
> that still puts me at having hundreds of certs needing remediation in a
> period where retail production systems are not allowed to be touched.
>
> Experience with past sunsets (e.g. sha-1) has proven that allowing
certificates to naturally expire results in a bad outcome - Subscribers are
somehow unaware of the sunset until their certificate is about to expire,
at which point they can't get a replacement certificate and don't have time
to fix their systems. The revocation requirement ensures that Subscribers
are aware of the sunset while the provision for continued issuance of
30-day duration certificates provides additional time to update systems.
The short window is the result of a compromise with certain CAs and
browsers that argued for no sunset period at all because underscores have
never been permitted in BR-compliant certificates. That conclusion would
in-turn trigger the 5-day revocation requirement from section 4.9.1.1 of
the BRs.
2) If a certificate is not used to host a URL (say for server to server
> communication or 2way SSL... what does it matter, and can we allow those to
> remain till natural expiration?
>
> This sounds like a case where a publicly-trusted TLS server certificate is
being used for something other than the intended purpose. Unfortunately,
doing that carries the risk that those certificates will need to adapt to
[sometime rapid] changes to the requirements for TLS server certificates.
This also happened with the sha-1 sunset and is a good example of why it's
not a good idea to use publicly-trusted TLS server certificates for other
purposes.
3) Is there any exception process available that will allow us to keep our
> existing certs through their validity?
>
> There is no process for granting an exception to the BRs without the
consequence of a potential audit finding for the CA. It's up to the CA to
determine if they want to take the risk of an audit finding. It would
likely help to quantify the problem in terms of how many certificates, how
much extra time would be required to replace them, what steps are being
taken to expedite replacement, and what the risk/consequences are of having
these certificates revoked prior to replacement.
Thank you
>
> On Monday, November 12, 2018 at 4:19:17 PM UTC-7, Wayne Thayer wrote:
> > As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
> > creating a sunset period for TLS certificates containing an underscore
> > ("_") character in the SAN. This practice was widespread until a year ago
> > when it was pointed out that underscore characters are not permitted in
> > dNSName name forms, and ballot 202 was proposed to create an exception to
> > RFC 5280 that would allow the practice to continue. When that ballot
> > failed, some CAs stopped allowing underscore characters in SANs and
> others
> > continued. Ballot SC12 is intended to resolve this inconsistency and
> > provide clear guidance to auditors.
> >
> > The sunset period defined by ballot SC12 is very short. Today Mozilla
> sent
> > an email to all CAs in our program informing them of this change and
> asking
> > them to take any steps necessary to comply [2].
> >
> > - Wayne
> >
> > [1]
> >
> https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
> > [2]
> >
> https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: CA Communication: Underscores in dNSNames
I need some clarification on something here
1) Why are legacy certs not being allowed to expire, and instead we are being
forced to replace in a very short window? We stopped issuing certs with
underscores as soon as our CA told us to (probably mid-September) but that
still puts me at having hundreds of certs needing remediation in a period where
retail production systems are not allowed to be touched.
2) If a certificate is not used to host a URL (say for server to server
communication or 2way SSL... what does it matter, and can we allow those to
remain till natural expiration?
3) Is there any exception process available that will allow us to keep our
existing certs through their validity?
Thank you
On Monday, November 12, 2018 at 4:19:17 PM UTC-7, Wayne Thayer wrote:
> As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
> creating a sunset period for TLS certificates containing an underscore
> ("_") character in the SAN. This practice was widespread until a year ago
> when it was pointed out that underscore characters are not permitted in
> dNSName name forms, and ballot 202 was proposed to create an exception to
> RFC 5280 that would allow the practice to continue. When that ballot
> failed, some CAs stopped allowing underscore characters in SANs and others
> continued. Ballot SC12 is intended to resolve this inconsistency and
> provide clear guidance to auditors.
>
> The sunset period defined by ballot SC12 is very short. Today Mozilla sent
> an email to all CAs in our program informing them of this change and asking
> them to take any steps necessary to comply [2].
>
> - Wayne
>
> [1]
> https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
> [2]
> https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
Paul Wouters via dev-security-policy writes: >Usually X509 is validated using standard libraries that only think of the TLS >usage. So most certificates for VPN usage still add EKUs like serverAuth or >clientAuth, or there will be interop problems. So just to make sure I've got this right, implementations are needing to add dummy TLS EKUs to non-TLS certs in order for them to "work"? In that case why not add a signalling EKU or policy value, a bit like Microsoft's systemHealthLoophole EKU (I don't know what its official name is, 1 3 6 1 4 1 311 47 1 3) where the normal systemHealth key usage is meant to indicate compliance with a system or corporate security policy and the systemHealthLoophole key usage is for systems that don't comply with the policy but that need a systemHealth certificate anyway. In theory there's the anyExtendedKeyUsage that seems to do something like this: If a CA includes extended key usages to satisfy such applications, but does not wish to restrict usages of the key, the CA can include the special KeyPurposeId anyExtendedKeyUsage in addition to the particular key purposes required by the applications. but thats vague enough, and little-supported enough, that expecting existing implementations to handle it correctly out of the box seems pretty risky. Better to define a new EKU, "tlsCompabitility", telling the relying party that the TLS EKUs are present for compatibility purposes and can be ignored if it's a non-TLS use. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
2018. december 6., csütörtök 16:12:37 UTC+1 időpontban Jakob Bohm a következőt írta: > On 06/12/2018 12:37, Sándor dr. Szőke wrote: > > 2018. december 5., szerda 20:45:25 UTC+1 időpontban Wayne Thayer a > > következőt írta: > >> .On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy < > >> dev-security-policy@lists.mozilla.org> wrote: > >> > >>> > >>> 1./ > >>> How your CA first became aware of the problem (e.g. via a problem report > >>> submitted to your Problem Reporting Mechanism, a discussion in > >>> mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and > >>> the time and date. > >>> > >>> 2018-11-29 20:15 CET > >>> Microsec received a notification email to the central email address from > >>> Alex Gaynor at Mozilla. > >>> > >>> In the email Alex Gaynor reported two misissued certificates: > >>> - > >>> https://crt.sh/?q=46FB3ACB357BBF2C4803FD23E02AF3085912E71164F8E90CE914C67A691597BE=cablint > >>> - > >>> https://crt.sh/?sha256=81673B2C2A101F8E1D0E934434290A69A6CC358D808D486439DF913FD9B96FE0 > >>> > >>> He requested to > >>> a) revoke these certificates > >>> b) notify the mozilla.dev.security.policy mailing list with > >>> retrospective details as described here: > >>> https://wiki.mozilla.org/CA/Responding_To_An_Incident > >>> > >>> Thank you for posting this incident report. I have created > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1512270 to track this issue. > >> > >>> > >>> 2./ > >>> A timeline of the actions your CA took in response. A timeline is a > >>> date-and-time-stamped sequence of all relevant events. This may include > >>> events before the incident was reported, such as when a particular > >>> requirement became applicable, or a document changed, or a bug was > >>> introduced, or an audit was done. > >>> > >>> > >>> 2018-11-22 around 16:15 CET > >>> Microsec issued 3 pcs CISCO VPN server certificates. > >>> See details in point 4. > >>> > >>> 2018-11-29 20:15 CET > >>> Microsec received a notification email to the central email address from > >>> Alex Gaynor as described in section 1. > >>> > >>> Why didn't Microsec detect this misissuance? > >> > > > > Microsec managed the CISCO VPN certificates separately from the TLS > > certificates. > > Microsec issued the CISCO VPN server certificates from a separate CA which > > is not used to issue TLS certificates. > > Microsec used separate policy for CISCO VPN server certificates and it was > > not clear that we shall follow the BR or not, because the BR says: > > > > "1.2. DOCUMENT NAME AND IDENTIFICATION > > This certificate policy (CP) contains the requirements for the issuance and > > management of publicly-trusted SSL certificates, as adopted by the > > CA/Browser Forum." > > > > The CISCO VPN server certificate is very similar to the TLS certificate but > > they are not the same. It was not clear for us that the CISCO VPN server > > certificates shall be treated as SSL/TLS certificate. > > > > The CISCO VPN server policy was not changed in March when we changed the > > TLS policies to reduce the lifetime of the TLS certificates to 2 years. > > The issued certificates were checked but to the old policy which allowed > > the issuance for 3 years, so the problem could not been detected. > > > > The Mozilla root program policy, section "1.1 Scope" defines precisely > which certificates are in scope for the Mozilla policy (which in turn > references the BRs for TLS server certificates). > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#11-scope > > The wording there should leave no doubt as to which of the mentioned > certicates, templates and policies need to comply. > > Each of the other root programs (Chrome, Apple, Microsoft, Oracle etc.) > have similar policy documents specifying their scope and additional > requirements. > You are right, the Mozilla Root Store Policy requirement is clear, Mozilla requires the CISCO VPN server certificate to fulfil the BR requirements. Other requirements shall be checked for specific requirements too. > > > > > >> 2018-11-29 20:44 CET > >>> Gergely Vanczák (director of the certification services) forwarded the > >>> email to dr. Sándor Szőke (deputy director of the certification services). > >>> > >>> 2018-11-30 09:27 CET > >>> Gergely Vanczák sent an email to the customer service and ordered to > >>> a) issue new certificates instead of the reported certificates with > >>> two years validity > >>> b) contact the customer regarding the replacement and agree with them > >>> the revocation date of the misissued certificates > >>> > >>> 2018-11-30 10:50 CET > >>> The customer service reported that there were three similar certificates > >>> not only two. > >>> > >>> 2018-11-30 10:55 CET > >>> Gergely Vanczák ordered to replace all three certificates. > >>> > >>> 2018-11-30 11:10 CET > >>> The new certificates has been issued with two years validity. The customer >
Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
On 06/12/2018 12:37, Sándor dr. Szőke wrote: > 2018. december 5., szerda 20:45:25 UTC+1 időpontban Wayne Thayer a következőt > írta: >> .On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> >>> 1./ >>> How your CA first became aware of the problem (e.g. via a problem report >>> submitted to your Problem Reporting Mechanism, a discussion in >>> mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and >>> the time and date. >>> >>> 2018-11-29 20:15 CET >>> Microsec received a notification email to the central email address from >>> Alex Gaynor at Mozilla. >>> >>> In the email Alex Gaynor reported two misissued certificates: >>> - >>> https://crt.sh/?q=46FB3ACB357BBF2C4803FD23E02AF3085912E71164F8E90CE914C67A691597BE=cablint >>> - >>> https://crt.sh/?sha256=81673B2C2A101F8E1D0E934434290A69A6CC358D808D486439DF913FD9B96FE0 >>> >>> He requested to >>> a) revoke these certificates >>> b) notify the mozilla.dev.security.policy mailing list with >>> retrospective details as described here: >>> https://wiki.mozilla.org/CA/Responding_To_An_Incident >>> >>> Thank you for posting this incident report. I have created >> https://bugzilla.mozilla.org/show_bug.cgi?id=1512270 to track this issue. >> >>> >>> 2./ >>> A timeline of the actions your CA took in response. A timeline is a >>> date-and-time-stamped sequence of all relevant events. This may include >>> events before the incident was reported, such as when a particular >>> requirement became applicable, or a document changed, or a bug was >>> introduced, or an audit was done. >>> >>> >>> 2018-11-22 around 16:15 CET >>> Microsec issued 3 pcs CISCO VPN server certificates. >>> See details in point 4. >>> >>> 2018-11-29 20:15 CET >>> Microsec received a notification email to the central email address from >>> Alex Gaynor as described in section 1. >>> >>> Why didn't Microsec detect this misissuance? >> > > Microsec managed the CISCO VPN certificates separately from the TLS > certificates. > Microsec issued the CISCO VPN server certificates from a separate CA which is > not used to issue TLS certificates. > Microsec used separate policy for CISCO VPN server certificates and it was > not clear that we shall follow the BR or not, because the BR says: > > "1.2. DOCUMENT NAME AND IDENTIFICATION > This certificate policy (CP) contains the requirements for the issuance and > management of publicly-trusted SSL certificates, as adopted by the CA/Browser > Forum." > > The CISCO VPN server certificate is very similar to the TLS certificate but > they are not the same. It was not clear for us that the CISCO VPN server > certificates shall be treated as SSL/TLS certificate. > > The CISCO VPN server policy was not changed in March when we changed the TLS > policies to reduce the lifetime of the TLS certificates to 2 years. > The issued certificates were checked but to the old policy which allowed the > issuance for 3 years, so the problem could not been detected. > The Mozilla root program policy, section "1.1 Scope" defines precisely which certificates are in scope for the Mozilla policy (which in turn references the BRs for TLS server certificates). https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#11-scope The wording there should leave no doubt as to which of the mentioned certicates, templates and policies need to comply. Each of the other root programs (Chrome, Apple, Microsoft, Oracle etc.) have similar policy documents specifying their scope and additional requirements. > > >> 2018-11-29 20:44 CET >>> Gergely Vanczák (director of the certification services) forwarded the >>> email to dr. Sándor Szőke (deputy director of the certification services). >>> >>> 2018-11-30 09:27 CET >>> Gergely Vanczák sent an email to the customer service and ordered to >>> a) issue new certificates instead of the reported certificates with >>> two years validity >>> b) contact the customer regarding the replacement and agree with them >>> the revocation date of the misissued certificates >>> >>> 2018-11-30 10:50 CET >>> The customer service reported that there were three similar certificates >>> not only two. >>> >>> 2018-11-30 10:55 CET >>> Gergely Vanczák ordered to replace all three certificates. >>> >>> 2018-11-30 11:10 CET >>> The new certificates has been issued with two years validity. The customer >>> has been informed about the replacement due to misissuance. It was on >>> Friday, so the customer asked a few days to be able to arrange the >>> installation of the new certificates in his IT systems. >>> >>> 2018-11-30 20:32 CET >>> dr. Sándor Szőke informed Alex Gaynor in email about the issuance of the >>> new certificates and the planned revocation of the original certificates. >>> >>> There was a small discussion between them about the reason of the problem >>> in a few emails in the following half hour. The
Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
2018. december 5., szerda 20:53:31 UTC+1 időpontban Gijs Kruitbosch a következőt írta: > On 05/12/2018 19:45, Wayne Thayer wrote: > > ..On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > 6./ > >> Explanation about how and why the mistakes were made or bugs introduced, > >> and how they avoided detection until now. > >> > >> Microsec manages the CISCO VPN cerver certificates separately from the TLS > >> certificates. The policy of the CISCO VPN servers was not changed when the > >> validity of the TLS certificates changed from 3 years to 2 years in March > >> 2018. > >> > > > > Why wasn't the policy for Cisco VPN servers updated? This points to a > > deeper failure to properly manage all of the profiles used to issue > > certificates that chain to publicly-trusted roots, and I would like to > > better understand what went wrong and how it will be prevented in the > > future? > > Adding some more questions on to this: does Microsec have any other > non-TLS cert policies that they "manage separately" from the TLS ones > (no matter how infrequently used), and if so how many, and have you > verified how any of those might qualify as TLS certs and thus fall under > the BR, and if so, that they abide by this validity BR? > > ~ Gijs We can issue other certificates which are not TLS but they are similar. These are: Domain Controller certificates VPN server certificates In case of these certificates we use only the following EKUs: serverAuth (1.3.6.1.5.5.7.3.1) for both clientAuth (1.3.6.1.5.5.7.3.2) only for Domain controller These are absolutely conformant to the BR requirements, so there is no such a problem with them. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
2018. december 5., szerda 20:45:25 UTC+1 időpontban Wayne Thayer a következőt írta: > .On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > 1./ > > How your CA first became aware of the problem (e.g. via a problem report > > submitted to your Problem Reporting Mechanism, a discussion in > > mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and > > the time and date. > > > > 2018-11-29 20:15 CET > > Microsec received a notification email to the central email address from > > Alex Gaynor at Mozilla. > > > > In the email Alex Gaynor reported two misissued certificates: > > - > > https://crt.sh/?q=46FB3ACB357BBF2C4803FD23E02AF3085912E71164F8E90CE914C67A691597BE=cablint > > - > > https://crt.sh/?sha256=81673B2C2A101F8E1D0E934434290A69A6CC358D808D486439DF913FD9B96FE0 > > > > He requested to > > a) revoke these certificates > > b) notify the mozilla.dev.security.policy mailing list with > > retrospective details as described here: > > https://wiki.mozilla.org/CA/Responding_To_An_Incident > > > > Thank you for posting this incident report. I have created > https://bugzilla.mozilla.org/show_bug.cgi?id=1512270 to track this issue. > > > > > 2./ > > A timeline of the actions your CA took in response. A timeline is a > > date-and-time-stamped sequence of all relevant events. This may include > > events before the incident was reported, such as when a particular > > requirement became applicable, or a document changed, or a bug was > > introduced, or an audit was done. > > > > > > 2018-11-22 around 16:15 CET > > Microsec issued 3 pcs CISCO VPN server certificates. > > See details in point 4. > > > > 2018-11-29 20:15 CET > > Microsec received a notification email to the central email address from > > Alex Gaynor as described in section 1. > > > > Why didn't Microsec detect this misissuance? > Microsec managed the CISCO VPN certificates separately from the TLS certificates. Microsec issued the CISCO VPN server certificates from a separate CA which is not used to issue TLS certificates. Microsec used separate policy for CISCO VPN server certificates and it was not clear that we shall follow the BR or not, because the BR says: "1.2. DOCUMENT NAME AND IDENTIFICATION This certificate policy (CP) contains the requirements for the issuance and management of publicly-trusted SSL certificates, as adopted by the CA/Browser Forum." The CISCO VPN server certificate is very similar to the TLS certificate but they are not the same. It was not clear for us that the CISCO VPN server certificates shall be treated as SSL/TLS certificate. The CISCO VPN server policy was not changed in March when we changed the TLS policies to reduce the lifetime of the TLS certificates to 2 years. The issued certificates were checked but to the old policy which allowed the issuance for 3 years, so the problem could not been detected. > 2018-11-29 20:44 CET > > Gergely Vanczák (director of the certification services) forwarded the > > email to dr. Sándor Szőke (deputy director of the certification services). > > > > 2018-11-30 09:27 CET > > Gergely Vanczák sent an email to the customer service and ordered to > > a) issue new certificates instead of the reported certificates with > > two years validity > > b) contact the customer regarding the replacement and agree with them > > the revocation date of the misissued certificates > > > > 2018-11-30 10:50 CET > > The customer service reported that there were three similar certificates > > not only two. > > > > 2018-11-30 10:55 CET > > Gergely Vanczák ordered to replace all three certificates. > > > > 2018-11-30 11:10 CET > > The new certificates has been issued with two years validity. The customer > > has been informed about the replacement due to misissuance. It was on > > Friday, so the customer asked a few days to be able to arrange the > > installation of the new certificates in his IT systems. > > > > 2018-11-30 20:32 CET > > dr. Sándor Szőke informed Alex Gaynor in email about the issuance of the > > new certificates and the planned revocation of the original certificates. > > > > There was a small discussion between them about the reason of the problem > > in a few emails in the following half hour. The summary of the details can > > be seen later. > > > > 2018-12-03 10:28 CET > > Monday morning the customer informed Microsec that he has successfully > > replaced all three certificates in his system. > > The misissued certificates has been revoked. > > > > > > 3./ > > Whether your CA has stopped, or has not yet stopped, issuing certificates > > with the problem. A statement that you have will be considered a pledge to > > the community; a statement that you have not requires an explanation. > > > > Our CA issued only those 3 certificates with this problem and it will not > > happen in the future again. > > > > > > 4./ > > A summary of the problematic
