Re: [FORGED] Re: [FORGED] Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
Paul Wouters via dev-security-policy writes: >I'm not sure how that is helpful for those crypto libraries who mistakenly >believe a certificate is a TLS certificate and thus if the EKU is not empty >it should have serverAuth or clientAuth. Sure, it wouldn't help with current libraries that neither acknowledge non-TLS use nor know about the tlsCompabitility EKU, but it would act as a signalling mechanism going forward to inform RP's about what's going on. So if you get notified about an apparently-wrong cert you can see the tlsCompabitility EKU and realise what's going on. Peter. ___ 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
2018. december 6., csütörtök 23:31:42 UTC+1 időpontban Peter Gutmann a
következőt írta:
>
> 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.
Absolutely agree.
The main reason to use EKU values is to define the targeted usage of the
certificate and the belonging keys. The EKU should be clear enough for the
software vendors to be able to select the proper certificate for their
application. The good separation and detailed requirement specification would
help the CAs to issue proper certificates.
If the present EKUs are not enough to fulfil this requirement a possible
solution can be to define further EKU values as you have proposed.
The alternative solution can be the way which was introduced by the European
regulation in the ETSI EN 319 412-5 which defines QCStatements for the
certificate profiles.
They are mandatory in the EU qualified certificates but can be used optionally
in other certificates too.
The existing proper QCStatement for the website authentication (TLS)
certificates is:
0.4.0.1862.1.6.3
id-etsi-qct-web OBJECT IDENTIFIER ::= { id-etsi-qcs-QcType 3 }
-- Certificate for website authentication as defined in Regulation (EU) No
910/2014
I have just asked the registration of this OID in the OID Repository at
oid-info.com
Sándor
___
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
On Thu, 6 Dec 2018, Peter Gutmann via dev-security-policy wrote: 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"? You understanding is correct. 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. I'm not sure how that is helpful for those crypto libraries who mistakenly believe a certificate is a TLS certificate and thus if the EKU is not empty it should have serverAuth or clientAuth. 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. As I stated earier, since often these certificates are re-used for the VPN server's TLS (openvpn, openconnect, etc) protocols or for their webgui's provisioning API, they will most likely want serverAuth anyway. btw for nss this got fixed recently: https://bugzilla.mozilla.org/show_bug.cgi?id=1252891 Paul ___ 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&opt=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&opt=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&opt=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 certif
Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec
> On Dec 5, 2018, at 16:49, Jakob Bohm via dev-security-policy > wrote: > > > > Another question of relevance: > > Does the applicable VPN hardware and software (Cisco VPN servers and > compatible VPN clients) work with certificates that omit all the TLS- > related EKUs, thus allowing future VPN certificates to fall outside the > BRs ? Speaking as an IKE/IPsec implementer. 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. Our implementation uses NSS which only weeks ago implemented IPsec profiles that causes non-empty EKU’s that miss serverAuth and clientAuth to validate correctly for IPsec. In other words, “no” is the answer to your question for the generic case. If Cisco VPN servers only need to talk to Cisco VPN clients, then maybe their implemention could do its Another issue is that some provisions webgui’s for IPsec use the VPN gateway’s TLS server, usually using the same certificate. Especially if also supporting other VPN protocols such as openvpn or anyconnect/openconnect. So those would really need serverAuth. Paul ___ 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
On 05/12/2018 20: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: ... > Further actions made: Microsec modified the CISCO VPN server policy to issue the certificates only for two years in the future. Microsec decided to discuss the situation of the CISCO VPN server certificates and make the necessary modifications (if needed) to fully comply with the BR requirements in case of CISCO VPN server certificates too. The reason of the problem is that Microsec couldn’t find clear instruction or specifications about the requirements regarding the CISCO VPN server certificates. They are very similar to the TLS certificates, but they have slightly different usage and different extended key usage values. Because these certificate can be used for TLS, as far as Mozilla is concerned, they **are** TLS certificates, and all Mozilla policies for TLS certificates apply. The main difference is that the CISCO VPN server certificates contain the following EKU values which should not be present in the TLS certificates: ipsecEndSystem (1.3.6.1.5.5.7.3.5), ipsecIntermediateSystem (1.3.6.1.5.5.8.2.2) The easiest way would be to manage the CISCO VPN server certificates as a TLS certificate. Do you perform linting on certificates issued under the TLS profile? Our questions are: is it allowed to issue CISCO VPN server certificates with the same CA which issues TLS certificates? Only if those certificates fully comply with Mozilla policy for TLS certificates. will not cause the extra EKU values any problems for the CABF in the (near) future? This problem is best answered by the CAB Forum (questi...@cabforum.org), but in my opinion the Baseline Requirements permit the issuance of certificates containing "extra" EKU values as long as they comply with section 7.1.4.2, including: - Extensions that do not apply in the context of the public Internet (such as an extendedKeyUsage value for a service that is only valid in the context of a privately managed network), unless: such value falls within an OID arc for which the Applicant demonstrates ownership, or the Applicant can otherwise demonstrate the right to assert the data in a public context These appear to be IETF OIDs for IETF standard IPSEC, applicable to the public Internet even if the specific CISCO servers only accept login from specific users. -- It is not clear to me that Cisco VPN server certificates meet the requirements that 'extensions apply in the context of the public Internet'. is it possible to send the CISCO VPN server pre-certificates to the CT log servers and include the answers in the certificate? This question is best answered by Cisco, but I think this should be possible, is it still really necessary to include these extra EKU values in the CISCO VPN server certificates, or can CISCO devices work with fully TLS compatible certificates? This is also a question for Cisco. Someone on this list may be able to provide an unofficial answer. Another question of relevance: Does the applicable VPN hardware and software (Cisco VPN servers and compatible VPN clients) work with certificates that omit all the TLS- related EKUs, thus allowing future VPN certificates to fall outside the BRs ? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ 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
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 ___ 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
.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&opt=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? 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 certificates. For each problem: number of > certs, and the date the first and last certs with that problem were issued. > > 2018-11-22 around 16:15 CET > Microsec issued 3 pcs CISCO VPN server certificates to the same customer > (Hungarian Chamber of State Notaries). > > The certificates were issued with three years validity under the ’ > Advanced Class 3 e-Szigno CA 2009’ by using the non eIDAS conformant > Certification Policies which covers all the certificate types rather than > electronic signature and website authentication. > > The Common names are: > > avpn.mokk.hu > bvpn.mokk.hu > fvpn.mokk.hu > > > > 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. > > The link to two of those certificates. > > https://crt.sh/?q=46FB3ACB357BBF2C4803FD23E02AF3085912E71164F8E90CE914C67A691597BE&opt=cablint > - > https://crt.sh/?sha256=81673B2C2A101F8E1D0E934434290A69A6CC358D808D486439DF913FD9B96FE0 > > All the three certificates had the same problem, the validity was three > years instead of two years. > > Is this the third certificate: https://crt.sh/?id=950822028 ? 6./ > Expla
Incident report - Misissuance of CISCO VPN server certificates by Microsec
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&opt=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 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. 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 certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. 2018-11-22 around 16:15 CET Microsec issued 3 pcs CISCO VPN server certificates to the same customer (Hungarian Chamber of State Notaries). The certificates were issued with three years validity under the ’ Advanced Class 3 e-Szigno CA 2009’ by using the non eIDAS conformant Certification Policies which covers all the certificate types rather than electronic signature and website authentication. The Common names are: avpn.mokk.hu bvpn.mokk.hu fvpn.mokk.hu 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. The link to two of those certificates. https://crt.sh/?q=46FB3ACB357BBF2C4803FD23E02AF3085912E71164F8E90CE914C67A691597BE&opt=cablint - https://crt.sh/?sha256=81673B2C2A101F8E1D0E934434290A69A6CC358D808D486439DF913FD9B96FE0 All the three certificates had the same problem, the validity was three years instead of two years. 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. Microsec issues only a very few CISCO VPN server certificates and these were the first issued certificates since the reduction of the allowed validity time from 3 years to two years. 7./ List of
