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 > >>> 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 (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 > >> -------------- > >> 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 > > > > > 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
