Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Incident report - Misissuance of CISCO VPN server certificates by Microsec
322 views
Skip to first unread message
dr. Sándor Szőke
Dec 5, 2018, 1:58:22 PM12/5/18
to mozilla-dev-s...@lists.mozilla.org
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 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.
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.
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.
Our questions are:
is it allowed to issue CISCO VPN server certificates with the same CA which issues TLS certificates?
will not cause the extra EKU values any problems for the CABF in the (near) future?
is it possible to send the CISCO VPN server pre-certificates to the CT log servers and include the answers in the certificate?
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?
Wayne Thayer
Dec 5, 2018, 2:45:25 PM12/5/18
to dr.szok...@gmail.com, mozilla-dev-security-policy
.On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy <
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?
> Is this the third certificate: https://crt.sh/?id=950822028 ?
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?
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.
>
> This response amounts to "we don't do this very often, so we're not
capable of doing it correctly". What steps have been, or will in the future
be taken to reduce this risk? For example, did you issue test certificates
using this profile?
> 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.
>
> 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 (ques...@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
--------------
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.
dev-secur...@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
>
> 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
>
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.
>
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.
>
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?
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.
>
capable of doing it correctly". What steps have been, or will in the future
be taken to reduce this risk? For example, did you issue test certificates
using this profile?
> 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.
>
> 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.
>
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.
>
Our questions are:
> is it allowed to issue CISCO VPN server certificates with the same
> CA which issues TLS certificates?
>
certificates.
will not cause the extra EKU values any problems for the CABF in
> the (near) future?
>
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
--------------
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?
>
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?
>
provide an unofficial answer.
Gijs Kruitbosch
Dec 5, 2018, 2:53:31 PM12/5/18
to Wayne Thayer, dr.szok...@gmail.com
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 <
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
> ..On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy <
> dev-secur...@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
> 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?
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
Jakob Bohm
Dec 5, 2018, 4:49:43 PM12/5/18
to mozilla-dev-s...@lists.mozilla.org
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-secur...@lists.mozilla.org> wrote:
>
>> ...
> .On Wed, Dec 5, 2018 at 1:58 PM dr. Sándor Szőke via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
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.
>
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
Paul Wouters
Dec 5, 2018, 5:56:54 PM12/5/18
to Jakob Bohm, mozilla-dev-s...@lists.mozilla.org
> On Dec 5, 2018, at 16:49, Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org> 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 ?
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
Sándor dr. Szőke
Dec 6, 2018, 9:40:07 AM12/6/18
to mozilla-dev-s...@lists.mozilla.org
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.
-----BEGIN CERTIFICATE-----
MIIGBDCCBOygAwIBAgIOAo036GS8afrtXndxlwowDQYJKoZIhvcNAQELBQAwgYUx
CzAJBgNVBAYTAkhVMREwDwYDVQQHDAhCdWRhcGVzdDEWMBQGA1UECgwNTWljcm9z
ZWMgTHRkLjEqMCgGA1UEAwwhQWR2YW5jZWQgQ2xhc3MgMyBlLVN6aWdubyBDQSAy
MDA5MR8wHQYJKoZIhvcNAQkBFhBpbmZvQGUtc3ppZ25vLmh1MB4XDTE4MTEyMjE1
MTUzMFoXDTIxMTEyMjE1MTUzMFowgYwxCzAJBgNVBAYTAkhVMREwDwYDVQQHDAhC
dWRhcGVzdDEtMCsGA1UECgwkTWFneWFyIE9yc3rDoWdvcyBLw7Z6amVneXrFkWkg
S2FtYXJhMRUwEwYDVQQDDAxhdnBuLm1va2suaHUxJDAiBgNVBAUTGzEuMy42LjEu
NC4xLjIxNTI4LjIuMy4yLjM5MTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALWOjXUkM5BwU947xo3CLOjlAqxal1qfgz2Zorhj9naYhMv36aFbVWmoo/OM
SvzKiwtRy1O2Oelyb2x5/bpBqyegzguyqpUUtnGLZbB93bjlv5hL7G8qr6SnngS5
menYhh/jtdP/bOlwn37S8Xzp22Mfo3isFwyy9gCcPNPhZsLDgoRBycXHCT7M2Ia5
k8p0XjOYpoVoBdVDLZV33b7T3PM7ru66N2JvC/mk9bxxb5l7pj7ovaLCTJNwUH0C
liEqCUV9bkkR6fcoryXzlyVIdSu9aZ+Tj4OivyIntACOf7bRMqSC59VUC5pwz2Gq
7SNdk69ktMs86cHxj+oxDSmu75UCAwEAAaOCAmcwggJjMA4GA1UdDwEB/wQEAwIF
oDAnBgNVHSUEIDAeBggrBgEFBQcDAQYIKwYBBQUHAwUGCCsGAQUFCAICMIIBKwYD
VR0gBIIBIjCCAR4wggEQBg8rBgEEAYGoGAIBAYEeAgcwgfwwJgYIKwYBBQUHAgEW
Gmh0dHA6Ly9jcC5lLXN6aWduby5odS9hY3BzMGUGCCsGAQUFBwICMFkMV0lzc3Vl
ZCB2aWEgZmFjZS10by1mYWNlIHJlZ2lzdHJhdGlvbi4gVGhlIHN1YmplY3Qgb2Yg
dGhlIGNlcnRpZmljYXRlIGlzIGEgbGVnYWwgcGVyc29uLjBrBggrBgEFBQcCAjBf
DF1SZWdpc3p0csOhY2nDs2tvciBhIHN6ZW3DqWx5ZXMgbWVnamVsZW7DqXMga8O2
dGVsZXrFkS4gQSB0YW7DunPDrXR2w6FueSBhbGFueWEgam9naSBzemVtw6lseS4w
CAYGBACPegEBMB0GA1UdDgQWBBQDIanOdT4mwgL4Pe0yP04jntXpmDAfBgNVHSME
GDAWgBQmtxgBrJx478Clh8ANPzya8otFgTAXBgNVHREEEDAOggxhdnBuLm1va2su
aHUwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5lLXN6aWduby5odS9hM2Nh
MjAwOS5jcmwwagYIKwYBBQUHAQEEXjBcMCkGCCsGAQUFBzABhh1odHRwOi8vYTNv
Y3NwMjAwOS5lLXN6aWduby5odTAvBggrBgEFBQcwAoYjaHR0cDovL3d3dy5lLXN6
aWduby5odS9hM2NhMjAwOS5jcnQwDQYJKoZIhvcNAQELBQADggEBAFi1ZTsfuJQh
KSeYQCgTa2eds/cW/KPuQc6q0xxF0v+jrH7/rRQ8/WxElWkoEOn413Ajl54Ur1va
VcGDShj+4LdCeIH0gJ+wsmV+jwfBUI0F0aSavq7c8xrjYAAHktzPzzjh2no8S/Qg
xZWV+C/g/bdGf3ajdb7aF26d3AwVEOarGnKiyGCbaCYHAX1feonTUBDN3wZWqTTF
0JFQR5Sn6Wb5HdVxCaik95s5Th962nzoQUFMuqEzqqUFWlx5c97eDpfIdUwJQLmZ
sZA+qRU8h7X9u6SBEfTMX5S+p2EsYMjN0JF+0/2C9/m/CRCs1Iml77Gyw+vwizbb
W83reM1v8F0=
-----END CERTIFICATE-----
> 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?
>
> 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.
> >
> > This response amounts to "we don't do this very often, so we're not
> capable of doing it correctly". What steps have been, or will in the future
> be taken to reduce this risk? For example, did you issue test certificates
> using this profile?
>
We have also started a discussion to make it absolutely clear how to manage these type of certificates in the future.
> > 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.
> >
> > 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?
Microsec supports the Certificate Transparency and all the TLS precertificates are sent to 3 CT log servers bedfore the issuance, but it did not happen with the CISCO VPN server certificates
Sándor dr. Szőke
Dec 6, 2018, 9:40:37 AM12/6/18
to mozilla-dev-s...@lists.mozilla.org
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.
Jakob Bohm
Dec 6, 2018, 10:12:37 AM12/6/18
to mozilla-dev-s...@lists.mozilla.org
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.
Sándor dr. Szőke
Dec 6, 2018, 11:04:07 AM12/6/18
to mozilla-dev-s...@lists.mozilla.org
Other requirements shall be checked for specific requirements too.
Peter Gutmann
Dec 6, 2018, 5:31:42 PM12/6/18
to Jakob Bohm, Paul Wouters, mozilla-dev-s...@lists.mozilla.org
Paul Wouters via dev-security-policy <dev-secur...@lists.mozilla.org> 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.
Paul Wouters
Dec 7, 2018, 12:19:50 PM12/7/18
to Peter Gutmann, Jakob Bohm, mozilla-dev-s...@lists.mozilla.org
On Thu, 6 Dec 2018, Peter Gutmann via dev-security-policy wrote:
> Paul Wouters via dev-security-policy <dev-secur...@lists.mozilla.org> 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.
> Paul Wouters via dev-security-policy <dev-secur...@lists.mozilla.org> 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.
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.
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
Sándor dr. Szőke
Dec 7, 2018, 7:02:11 PM12/7/18
to mozilla-dev-s...@lists.mozilla.org
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.
>
> 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.
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
Peter Gutmann
Dec 7, 2018, 7:38:36 PM12/7/18
to Paul Wouters, mozilla-dev-s...@lists.mozilla.org, Jakob Bohm
Paul Wouters via dev-security-policy <dev-secur...@lists.mozilla.org> 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.
0 new messages