Closed Bug 1195115 Opened 4 years ago Closed 2 years ago
Swisscom: certificates without DNS names in subject
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150806001005 Actual results: Swisscom is an EV-qualified CA trusted by Mozilla that issues certificates with only email mentioned in subjectAltName. Clients have to rely on Common Name for validation. X509v3 Subject Alternative Name: email:firstname.lastname@example.org SHA1 certificates: Expired certificate — https://crt.sh/?id=1204599 Current certificate— https://crt.sh/?id=4852068 -----BEGIN CERTIFICATE----- MIIFrjCCBJagAwIBAgIQJGDBELbh9b03Jo0plPLJhDANBgkqhkiG9w0BAQUFADBl MQswCQYDVQQGEwJjaDERMA8GA1UEChMIU3dpc3Njb20xJTAjBgNVBAsTHERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2VydmljZXMxHDAaBgNVBAMTE1N3aXNzY29tIFJ1Ymlu IENBIDEwHhcNMTQwODE0MTEwNTIzWhcNMTcwODE0MTEwNTIzWjCBsjELMAkGA1UE BhMCQ0gxDTALBgNVBAgTBEJlcm4xDTALBgNVBAcTBEJlcm4xHjAcBgNVBAoTFVN3 aXNzY29tIChTY2h3ZWl6KSBBRzEgMB4GA1UECxMXQWxlcnRpbmcgJiBNb2JpbGl6 YXRpb24xHDAaBgNVBAMTEyouc3dpc3Njb20tYWxhcm0uY2gxJTAjBgkqhkiG9w0B CQEWFmluZm9Ac3dpc3Njb20tYWxhcm0uY2gwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDYc/d5Qdo1VDZIB6wkDzTLXJSpe/lyUcfmlCGAtlDj04UbZ8G9 mRdYee2L9jeVWwRLGAUiWPExOWZBIEh7NPLQVQ/QQQ/XCVlR4EWwtxMZHZHDTtGg ESjnHCKHqufZpNk6YfanSa7HsHQ8m3pBpk0SiZ6p78tzG5qDfQPaX3FdwHK8Ts3D brMPRbnJyUl9/pfmE5MzLueZbcYPvOz5Cz2a+bOdZN8nouBw/Cnegg+e9Tq7KGaF TY0gA0IfUCaOA+qmXYx3MXBI/7X148mBB8tsX5zV//eBMql96iGQl5JfkUiSKBdA zngGzV91c7FAphlyoNRhmJKetCGD3+JSIHedAgMBAAGjggIKMIICBjAfBgNVHSME GDAWgBQtwqejYz4/g0erSDM2gYX31OmswDB2BggrBgEFBQcBAQRqMGgwLgYIKwYB BQUHMAGGImh0dHA6Ly9vY3NwLnN3aXNzZGlnaWNlcnQuY2gvcnViaW4wNgYIKwYB BQUHMAKGKmh0dHA6Ly9haWEuc3dpc3NkaWdpY2VydC5jaC9zZGNzLXJ1YmluLmNy dDBIBgNVHSAEQTA/MD0GBmCFdAFTBDAzMDEGCCsGAQUFBwIBFiVodHRwOi8vd3d3 LnN3aXNzZGlnaWNlcnQuY2gvZG9jdW1lbnRzMIG5BgNVHR8EgbEwga4wMKAuoCyG Kmh0dHA6Ly9jcmwuc3dpc3NkaWdpY2VydC5jaC9zZGNzLXJ1YmluLmNybDB6oHig doZ0bGRhcDovL2xkYXAuc3dpc3NkaWdpY2VydC5jaC9DTj1Td2lzc2NvbSUyMFJ1 YmluJTIwQ0ElMjAxLGRjPXJ1YmluLGRjPXN3aXNzZGlnaWNlcnQsZGM9Y2g/Y2Vy dGlmaWNhdGVSZXZvY2F0aW9uTGlzdD8wDgYDVR0PAQH/BAQDAgWgMBMGA1UdJQQM MAoGCCsGAQUFBwMBMCEGA1UdEQQaMBiBFmluZm9Ac3dpc3Njb20tYWxhcm0uY2gw HQYDVR0OBBYEFN84maVvYJldpI95dIrl5ScOTwNBMA0GCSqGSIb3DQEBBQUAA4IB AQAK/QW91rTldjIvYi74IIN7Ua1PgSNArFQJSMYeic08F+DMhTCDLJs8159JEUPn T5ZLRqFx/qsrRn1CrGbdJcppd2ZlTAckmnz/UiCWZVy8pOcPWlWYPErwiU8igxkJ yBg3RuZxcIkbHDEVTFMGnKakkMWpLJUzjz8npmNByDB6uQLggPrIatKy8MyW2Wh1 wfSuQLoOYu7oIZPwb8VOHdzfVccKUqjksntScTdP9V3XxLiwKojav6JK5+GoP7hg 96LcHGoupTGCj6T5wHLZwbFySAaoHrJT4uRfnjQUPqaZu0BSeN/15ePktSK8Q5SS AmwEkaJcX2HZ9qWXcV3VtM1N -----END CERTIFICATE----- CT logs aren't aware of SHA2 certificates, so I have manually uploaded the one issued on 29 July 2015 to the Certly log. Current certificate — https://crt.sh/?id=8890411 -----BEGIN CERTIFICATE----- MIIGnTCCBYWgAwIBAgIRAJMLeGpMTfgDbdbOaNSBQ/MwDQYJKoZIhvcNAQELBQAw ZzELMAkGA1UEBhMCY2gxETAPBgNVBAoTCFN3aXNzY29tMSUwIwYDVQQLExxEaWdp dGFsIENlcnRpZmljYXRlIFNlcnZpY2VzMR4wHAYDVQQDExVTd2lzc2NvbSBTbWFy YWdkIENBIDIwHhcNMTUwNzI5MDg0MjI5WhcNMTgwNzI4MDg0MjI5WjCBsjELMAkG A1UEBhMCQ0gxDTALBgNVBAgTBEJlcm4xDTALBgNVBAcTBEJlcm4xHjAcBgNVBAoT FVN3aXNzY29tIChTY2h3ZWl6KSBBRzEgMB4GA1UECxMXQWxlcnRpbmcgJiBNb2Jp bGl6YXRpb24xHDAaBgNVBAMTEyouc3dpc3Njb20tYWxhcm0uY2gxJTAjBgkqhkiG 9w0BCQEWFmluZm9Ac3dpc3Njb20tYWxhcm0uY2gwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDYc/d5Qdo1VDZIB6wkDzTLXJSpe/lyUcfmlCGAtlDj04Ub Z8G9mRdYee2L9jeVWwRLGAUiWPExOWZBIEh7NPLQVQ/QQQ/XCVlR4EWwtxMZHZHD TtGgESjnHCKHqufZpNk6YfanSa7HsHQ8m3pBpk0SiZ6p78tzG5qDfQPaX3FdwHK8 Ts3DbrMPRbnJyUl9/pfmE5MzLueZbcYPvOz5Cz2a+bOdZN8nouBw/Cnegg+e9Tq7 KGaFTY0gA0IfUCaOA+qmXYx3MXBI/7X148mBB8tsX5zV//eBMql96iGQl5JfkUiS KBdAzngGzV91c7FAphlyoNRhmJKetCGD3+JSIHedAgMBAAGjggL2MIIC8jAfBgNV HSMEGDAWgBTgCARwTuPrRrZ1gm4wepSA0+PufTAOBgNVHQ8BAf8EBAMCBaAwgYEG CCsGAQUFBwEBBHUwczA2BggrBgEFBQcwAYYqaHR0cDovL29jc3Auc3dpc3NkaWdp Y2VydC5jaC9zZGNzLXNtYXJhZ2QyMDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN3 aXNzZGlnaWNlcnQuY2gvc2Rjcy1zbWFyYWdkMi5jcnQwggEUBgNVHSAEggELMIIB BzCCAQMGB2CFdAFTEQAwgfcwLAYIKwYBBQUHAgEWIGh0dHA6Ly93d3cuc3dpc3Nk aWdpY2VydC5jaC9jcHMvMIHGBggrBgEFBQcCAjCBuRqBtlJlbGlhbmNlIG9uIHRo ZSBTd2lzc2NvbSBSb290IENlcnRpZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1bWVz IGFjY2VwdGFuY2Ugb2YgdGhlIHRoZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0ZXJt cyBhbmQgY29uZGl0aW9ucyBvZiB1c2UgYW5kIHRoZSBTd2lzc2NvbSBDZXJ0aWZp Y2F0ZSBQcmFjdGljZSBTdGF0ZW1lbnQuMIHBBgNVHR8EgbkwgbYwM6AxoC+GLWh0 dHA6Ly9jcmwuc3dpc3NkaWdpY2VydC5jaC9zZGNzLXNtYXJhZ2QyLmNybDB/oH2g e4Z5bGRhcDovL2xkYXAuc3dpc3NkaWdpY2VydC5jaC9DTj1Td2lzc2NvbSUyMFNt YXJhZ2QlMjBDQSUyMDIsZGM9c21hcmFnZDIsZGM9c3dpc3NkaWdpY2VydCxkYz1j aD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0PzAdBgNVHSUEFjAUBggrBgEFBQcD AQYIKwYBBQUHAwIwIQYDVR0RBBowGIEWaW5mb0Bzd2lzc2NvbS1hbGFybS5jaDAd BgNVHQ4EFgQU3ziZpW9gmV2kj3l0iuXlJw5PA0EwDQYJKoZIhvcNAQELBQADggEB AEaj2rDUzDRD3Snlj1IIH0LtxRFma7EbSpvHd/JvC7BiA3zR7cVMbW19Yyu++/tK dkQKozeEfdgiuL2FiMAjnLtTOicVhpGsyqqQiL9s4J+2Gm9TpNMuQfAnZcs5IIf3 S71gvtMEE6kbY1TRA8IT+cgSX679XQLaDqK3NTCUsltAqtV+L1p/nrKH5Tptn87G MW8ZyNpkMZ3qyUIzkHOMRXJmyIlgQrFH6H9GsXEamdaY1H/X6+OliYxgi+BUlkzE FUD62rdT6iIDVvLf3KUEAx4VfkOumuIULG/YTF9d98i04EmNe6glLU35Bfi6FndL UZZ49QhqnJIfrsa8gWraT6I= -----END CERTIFICATE-----
Patrick, Please respond to this bug to explain why Swisscom has issued SSL certs without DNS name in the subjectAltName. CAB-Forum-BR-1.3.0, section 22.214.171.124.1: Subject Alternative Name Extension Required/Optional: Required Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully‐Qualified Domain Name or an iPAddress containing the IP address of a server...
Oops. I should have addressed this to Freddy... > Patrick, Please respond to this bug to explain why Swisscom has issued SSL > certs without DNS name in the subjectAltName. > > CAB-Forum-BR-1.3.0, section 126.96.36.199.1: Subject Alternative Name Extension > Required/Optional: Required > Contents: This extension MUST contain at least one entry. Each entry MUST be > either a dNSName containing > the Fully‐Qualified Domain Name or an iPAddress containing the IP address of > a server...
This was noted in their response to the CA Communication... >>> ACTION #4: Workarounds were implemented to allow mozilla::pkix to handle the things listed here https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix. We plan to remove these workarounds soon, so that new certificates with these problems will fail. Please check your certificate issuance to ensure you are no longer issuing certificates with these problems. The purpose of this question is to identify interoperability problems that may arise when we make the planned code changes, so we will appreciate your diligence in investigating your certificate issuance practices and previously issued certificates before you respond to this question. Please select all of the issues in the list below that exist in currently-valid certificates that chain to your root certificates in Mozilla's program. (required) >> 9. dNSName/iPAddress is only in the subject CN, and not in the subjectAltName. > There are several hundreds of certificates with this problem. We are still issuing such kind of certificates and the last one: Valid From 01. June 2015, 11:22:23 UTC (GMT) Valid Until 31. May 2018, 11:22:23 UTC (GMT) So, I'll track this as a BR-Compliance issue.
Whiteboard: BR Compliance
Assignee: kwilson → freddy.kaiser
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Hello, - We acknowledge that indeed our Certificate Authority still issues (non EV) SSL Server Certificates without a valid Subject Alternative Name. - In the last communication regarding this topic in June 2015, we stated that we were still issuing such kind of certificates and we mentioned that there were several hundred of them. This has not changed until today. - Starting immediately, we are putting into effect all necessary technical and administrative actions in order to assure that from now on: 1) Our Registration Authorities will thoughtfully proof all incoming certificate requests in order to assure that for SSL Server Certificates a Subject Alternative Name exist, contains at least a valid DNS Name or IP and that at least one of its entries is the same as the Common Name attribute from the Subject field, in case the latter exists, conforming to the CAB Forum Baseline Requirements, section 188.8.131.52.1. 2) Our Registration Authorities are aware of the existence of already issued SSL Certificates which do not contain a valid Subject Alternative Name as well as the implications of this, together with a recommendation to start a replacement action of such incorrect certificates in so far as it is feasible. - Could you please tell at which point in time the current mechanism of fallback to the Common Name will be removed? In other words, when will Internet Browsers start to identify SSL Certificates with the aforementioned problem as not trusted? Thank you very much. Kind Regards, Freddy Kaiser Swisscom Digital Certficate Services
Cool, thanks! Quite late response though, so I have already disabled trust for Swisscom on my sister's Android phone and was planning to do so on all my family members' devices. Hope I won't need to do this. Below are the bugs regarding removing CN fallback. https://bugzilla.mozilla.org/show_bug.cgi?id=552346 https://code.google.com/p/chromium/issues/detail?id=308330
Thanks for the infos about the bugs, both are still not "done" and for Mozilla even no assignment yet to be done. Any more details by when this will be active? Anything else we should do for this issue in order to have it marked "Resolved"?
(In reply to Adm Selec from comment #5) .. > Below are the bugs regarding removing CN fallback. > https://bugzilla.mozilla.org/show_bug.cgi?id=552346 > https://code.google.com/p/chromium/issues/detail?id=308330 (In reply to Freddy Kaiser from comment #6) > Thanks for the infos about the bugs, both are still not "done" and for > Mozilla even no assignment yet to be done. Any more details by when this > will be active? Those are not the bugs for removing CN fallback for Firefox. The bug you're looking for is bug 1245280. In this bug we disabled CN fallback for all certificates with a notBefore date later than 23 August 2016. This shipped in Firefox 48, which is the current release. As a result, all newly-issued certificates that do not have a subject alternative name extension with the appropriate DNS name entries will not validate successfully in Firefox.
Summary: Swisscom certificates without DNS names in subjectAltName → Swisscom: certificates without DNS names in subjectAltName
Component: CA Certificates → CA Certificate Mis-Issuance
Whiteboard: BR Compliance → [ca-compliance]
Swisscom stopps issuing SSL certificates. The websites trust bit will be removed - see https://bugzilla.mozilla.org/show_bug.cgi?id=1359515. As no additional SSL certificates will be issued and the acceptance of the existing certificates will be terminated, we suggest to close this issue.
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
corrected wrong reason
Resolution: INVALID → WONTFIX
You need to log in before you can comment on or make changes to this bug.