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 < > [email protected]> 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 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 ? > I could not find the third misissued certificate on the crt.sh, so I copy the certificate here: -----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? As I wrote above it was not clear for us that the CISCO VPN server certificates shall be managed as TLS certificates or not because there is no specific requirement for that. > > 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 already modified our CISCO VPN server policy, reduced the lifetime to the certificates to 2 years. 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. > OK, we will do that in the future if we have the proper answers from CISCO. > 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? Yes, we check all the issued TLS certificates with cablint before the publication. In case of any error message the certificate is revoked immediately and not published. 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 > > 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 ([email protected]), > 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. These questions shall be asked from CISCO _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
