Certificate with space in CommonName found on deutschepost.de

[Hanno Böck]

Hi,

I'm not sure if this is the right place to discuss this, but I thought
this should be brought up somewhere.

On the ssllabs mailing list someone pointed out that the webpage
www.deutschepost.de
causes an error in current Firefox versions.
(An error occurred during a connection to www.deutschepost.de. security
library: improperly formatted DER-encoded message. (Error code:
sec_error_bad_der)

(Chrome accepts the cert)

Kurt Roeckx pointed out that the CommonName contains a space before the
domain name. This is of course invalid, so I think Firefox is right to
reject this.

What made me especially curious: It seems Deutsche Post is its own sub
CA, sigend by Global sign. Deutsche Post is the german postal service,
I don't really know why they would have a CA.

Anyway, a CA creates an invalid certificate for its own webpage. It
doesn't look like any kind of attack or something, but I wonder if this
is in violation of any policies.

cu,
--
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

[Steve Roylance]

Hi Hanno,

Thanks for the heads up.

We did have some issues with an intermediate, where some DNSName constraints were incorrectly encoded with trailing spaces and although those CA's should have been replaced (to correct the chain) some did linger on. I'm responsible for communication to Deutsch Post's team so I'll investigate when I'm back from vacation and ask them to correct. There's no major issue other than clearing out the incorrect issuing CA's. Most browsers accept the constraints where as firefox did not.

It seems from your description we have the opposite issue here.

Thanks for highlighting.

I'm back into the office next week.

Steve

Sent from my iPhone

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Brian Smith]

On Fri, Apr 10, 2015 at 1:09 AM, Steve Roylance
<steve.r...@globalsign.com> wrote:
> We did have some issues with an intermediate, where some DNSName constraints were incorrectly encoded with trailing spaces and although those CA's should have been replaced (to correct the chain) some did linger on. I'm responsible for communication to Deutsch Post's team so I'll investigate when I'm back from vacation and ask them to correct. There's no major issue other than clearing out the incorrect issuing CA's. Most browsers accept the constraints where as firefox did not.
>
> It seems from your description we have the opposite issue here.

The problem isn't with the subject CN. The problem is indeed that the
intermediate CA certificate has trailing spaces at the end of some of
the dNSName entries. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1153204#c2.

Thanks, Steve, for cluing us into that.

Cheers,
Brian

[Kurt Roeckx]

Hi,

As I understand it from Brian Smith's comment in this bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1153204

The reason for rejecting it is the trailing space in the
DNSName. So it has both a leading space in the CN, and trailing
space in the DNSName.


Kurt

On Fri, Apr 10, 2015 at 11:09:44AM +0000, Steve Roylance wrote:
> Hi Hanno,
>
> Thanks for the heads up.
>

> We did have some issues with an intermediate, where some DNSName constraints were incorrectly encoded with trailing spaces and although those CA's should have been replaced (to correct the chain) some did linger on. I'm responsible for communication to Deutsch Post's team so I'll investigate when I'm back from vacation and ask them to correct. There's no major issue other than clearing out the incorrect issuing CA's. Most browsers accept the constraints where as firefox did not.
>
> It seems from your description we have the opposite issue here.
>

[Peter Gutmann]

Did anyone save a copy of the cert chain? I'd like to add it to my collection
of broken cer^H^H^H^H^Hcert parser test vectors, but the site has been fixed
and the Bugzilla entry doesn't contain it.

Peter.

[Hanno Böck]

Here you go.

Is your collection public?

[Kurt Roeckx]

On Sat, Apr 11, 2015 at 10:44:38AM +0000, Peter Gutmann wrote:
> Did anyone save a copy of the cert chain? I'd like to add it to my collection
> of broken cer^H^H^H^H^Hcert parser test vectors, but the site has been fixed
> and the Bugzilla entry doesn't contain it.

The site hasn't been fixed, at least not for me. Here are the
certificates I get:
-----BEGIN CERTIFICATE-----
MIIF4jCCBMqgAwIBAgIKE0okhgABAAAV7jANBgkqhkiG9w0BAQUFADBsMQswCQYD
VQQGEwJERTEcMBoGA1UECBMTTm9yZHJoZWluLVdlc3RmYWxlbjENMAsGA1UEBxME
Qm9ubjEWMBQGA1UEChMNRGV1dHNjaGUgUG9zdDEYMBYGA1UEAxMPRFBESEwgVExT
IENBIEkzMB4XDTE0MTAxMzEwMzIwOVoXDTE1MTAxMzEwMzIwOVowdDELMAkGA1UE
BhMCREUxHDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xDTALBgNVBAcTBEJv
bm4xGTAXBgNVBAoTEERldXRzY2hlIFBvc3QgQUcxHTAbBgNVBAMTFCB3d3cuZGV1
dHNjaGVwb3N0LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAobD+
8YmI60VujninLW77uEv22Rd6hNjJCyTeENqUtqEhPPYICtAaEqlHW82QHGYYBSvh
ztjXWX+mmNMG2bzH9W4GRsFxrnVilr9gKcn/kEruLK+Chzy/ce2Ttx+xcuN1mqxk
9+1Ysh2FjllgFGypCNDtT8ixx4Z2/MIHC0LHgb35vvzRvZDHG7Kbb+9UIUeFO1bQ
e3aaVvy01CUTLZvOAO2n5hZSDjvIBV7WCFwLlz5IIeEyxrKU43yVqyb+fCrJTg/x
iLaz/0TeUg6AitTZ79qkrNyFx/yRIKqkb+eynA+R1wxdfGEUPxiUES5RcAqzIRSh
RdkX11gKHV/GDfFkEQIDAQABo4ICfDCCAngwXwYDVR0RBFgwVoITd3d3LmRldXRz
Y2hlcG9zdC5kZYITd3d3LmRldXRzY2hlcG9zdC5kZYIZcG9zdGlkZW50LmRldXRz
Y2hlcG9zdC5kZYIPZGV1dHNjaGVwb3N0LmRlMB0GA1UdDgQWBBSVBlyRSXz0lsP8
I4spw9nxUHrNLDAfBgNVHSMEGDAWgBTIAwLewLGrg8Ue/gf3eL3lgwSIfTBBBgNV
HR8EOjA4MDagNKAyhjBodHRwOi8va2V5c2VydmVyLmRobC5jb20vcGtpL2kzL2Rw
ZGhsX3Rsc19pMy5jcmwwcQYIKwYBBQUHAQEEZTBjMCMGCCsGAQUFBzABhhdodHRw
Oi8vb2NzcC1nMy5kaGwuY29tLzA8BggrBgEFBQcwAoYwaHR0cDovL2tleXNlcnZl
ci5kaGwuY29tL3BraS9pMy9kcGRobF90bHNfaTMuY3J0MAsGA1UdDwQEAwIFoDA8
BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiB4KwqgvzBE4T9gQ+F6qVpg+U3gQ26
xlmE8d9cAgFkAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATBGBgNV
HSAEPzA9MDsGBmeBDAECAjAxMC8GCCsGAQUFBwIBFiNodHRwOi8va2V5c2VydmVy
LmRobC5jb20vcmVwb3NpdG9yeTAnBgkrBgEEAYI3FQoEGjAYMAoGCCsGAQUFBwMC
MAoGCCsGAQUFBwMBMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4G
CCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzANBgkqhkiG9w0BAQUF
AAOCAQEALgC5xcnv8uPAbnYCr5U9zmp8DKvLyqlmsCcS3hxpF0761IJ0t3wtcvtG
3WMQXx03QUhiO64u2f8drqJEDLwAWmlVNBLKfzopWgBUhyqTgFfWO4L49phNyzS/
uR9ESWFt/DUw5Jb4YcnfRyAR59YS2+P4ZIPRvE0P1uaqrpkqJr0vcQPpvu7fF7Nw
CqseJlpVefNSvhFr8Ss0kLlBdi3JAbszT22J10Ru0XVQ0rGin7VjEGnoG7tuzVaC
543d1bJmFoKqemJL2tp/flee0PrbUSrc5jDWd61SsY07U7AmCBUiZEBNMXna++eS
k+i0QbjPTN5pqdS7AfSCPPzGyRqhDg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIPhDCCDmygAwIBAgIRQM1zZ4GZ4gfwpQtUYye3Ne0wDQYJKoZIhvcNAQEFBQAw
XDELMAkGA1UEBhMCQkUxFTATBgNVBAsTDFRydXN0ZWQgUm9vdDEZMBcGA1UEChMQ
R2xvYmFsU2lnbiBudi1zYTEbMBkGA1UEAxMSVHJ1c3RlZCBSb290IENBIEcyMB4X
DTEzMDcxNjAwMDAwMFoXDTE4MDcxNjAwMDAwMFowbDELMAkGA1UEBhMCREUxHDAa
BgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xDTALBgNVBAcTBEJvbm4xFjAUBgNV
BAoTDURldXRzY2hlIFBvc3QxGDAWBgNVBAMTD0RQREhMIFRMUyBDQSBJMzCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALgmkAt1Z2MGFEy0Y/sUmbG/uY2R
4oUfgKqdq2W9kNtjhWmVUDogXW9ZMMnckOwjgAJq7A9p3ZV7T/akbf9L0x1nH3aq
B+AB4X41UJq4+7TD0hH21E17UQFYmcu+HjhJ+yC7MppNIUCMqHZSpsPs4XAdaxGu
iCIMMrLkXAsQC9cgud+sam1ioS8rU50DJdP889RBqFfS/DYLrZUcpJEFpKv6pn/T
/o24Szqyn9mNNo9gz9Hw47ppyeG7EkFm4L96kZ27KcKOtMPsGBfH+AGFg40ecVCj
n3zeQO4ryMhcQLK8PpBxNnA+OjcLyNrkOWpbwLXmbfmfRU4XG1u+25QMwlcCAwEA
AaOCDC8wggwrMA4GA1UdDwEB/wQEAwIBBjBXBgNVHSAEUDBOMAgGBmeBDAECAjBC
BgorBgEEAaAyATwBMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNp
Z24uY29tL3JlcG9zaXRvcnkvMBIGA1UdEwEB/wQIMAYBAf8CAQAwggp7BgNVHR4E
ggpyMIIKbqCCCjgwEYIPYWRyZXNzZGlhbG9nLmRlMBSCEmFkcmVzcy1yZXNlYXJj
aC5kZTAQgg5hZXJvbG9naWMuYWVybzARgg9hbGxlc25lYmVuYW4uZGUwE4IRY2F0
aGF5cGFjaWZpYy5jb20wD4INY2xlYXItbWFpbC5kZTAMggpjbGl4bWl4LmRlMAqC
CGNvdmlzLmRlMBGCD2RldXRzY2hlcG9zdC5kZTAUghJkZXV0c2NoZXBvc3QubG9j
YWwwHYIbZGV1dHNjaGVwb3N0LXNhZmUtb25saW5lLmRlMByCGmRldXRzY2hlLXNh
bW1sZXJtdWVuemVuLmRlMAiCBmRobC5hdDAIggZkaGwuY2gwC4IJZGhsLmNvLnVr
MAmCB2RobC5jb20wDIIKZGhsLmNvbS5jbzAMggpkaGwuY29tLmhrMAyCCmRobC5j
b20ucGwwCIIGZGhsLmRlMAiCBmRobC5lZTAIggZkaGwuZXMwCIIGZGhsLm5sMA+C
DWRobGJlbmVsdXgubmwwGIIWZGhsLWJ1c2luZXNzcG9ydGFsLmNvbTAYghZkaGwt
Y29ycG9yYXRlLXdlYXIuY29tMBGCD2RobGRhc2hib2FyZC5zZTATghFkaGwtZGVs
aXZlcm5vdy5kZTAWghRkaGxldXJvbmV0c3RhdHVzLmNvbTATghFkaGxleHByZXNz
ZWFzeS5zZTARgg9kaGxleHRlcm5hbC5jb20wD4INZGhsZnJlaWdodC5kazAPgg1k
aGxmcmVpZ2h0LmVlMA+CDWRobGZyZWlnaHQuZmkwD4INZGhsZnJlaWdodC5sdjAP
gg1kaGxmcmVpZ2h0Lm5vMA+CDWRobGZyZWlnaHQuc2UwH4IdZGhsLWdlc2NoYWVm
dHNrdW5kZW5wb3J0YWwuZGUwFYITZGhsZ2xvYmFsbWFpbC5jby51azATghFkaGxn
bG9iYWxtYWlsLmNvbTAUghJkaGwtZ2xvYmFsbWFpbC5jb20wDoIMZGhsaXRub3cu
Y29tMBuCGWRobC1rdW5kZW5hdWZzY2hhbHR1bmcuZGUwFYITZGhsc2VydmljZWNl
bnRlci5zZTAUghJkaGxzZXJ2aWNlcG9pbnQuc2UwEIIOZGhsc2VydmljZXMuaXQw
DYILZGhsdHdlYi5jb20wDYILZGhsLXVzYS5jb20wFoIUZGhsLXZlcnNhbmRwb3J0
YWwuZGUwE4IRZGhsLXdlYmNoZWNrZXIuZGUwEIIOZGhsd2VicG9ydC5jb20wGYIX
ZGllbnN0bGVpc3RlcmthdGFsb2cuZGUwEYIPZGllcmVkYWt0aW9uLmRlMBqCGGRp
cmVrdG1hcmtldGluZ2NlbnRlci5kZTAPgg1kaXJla3RwbHVzLmRlMAqCCGRwY29t
LmRlMAuCCWRwZGhsLmNvbTAMggpkcC1kaGwuY29tMAqCCGRwZGhsLmRlMAuCCWRw
LWRobC5kZTATghFkcC1pdHNvbHV0aW9ucy5kZTAKgghkcHduLmNvbTAJggdkcHdu
LmRlMAqCCGRwd24ubmV0MA2CC2Rwd25yZWYuY29tMA+CDWUtZGF0YWdhdGUuZGUw
DYILZWZpbGlhbGUuZGUwE4IRZWlua2F1ZmFrdHVlbGwuZGUwCoIIZXBvc3QuZGUw
DoIMZXBvc3QtZ2thLmRlMAqCCGV4ZWwuY29tMBCCDmV4cHJlc3NlYXN5LnNlMBiC
FmZpbGlhbGtvbW11bmlrYXRpb24uZGUwDoIMZm9ydW1nZWxiLmRlMBSCEmdsb2Jh
bG1haWwtcGl0LmNvbTAQgg5pYmdzdGFyc2hvcC5pdDAOggxpbnRyYXNoaXAuY2gw
DoIMaW50cmFzaGlwLmRlMBKCEGludHJhc2hpcC1kaGwuYXQwEoIQaW50cmFzaGlw
LWRobC5iZTAVghNpbnRyYXNoaXAtZGhsLmNvLnVrMBKCEGludHJhc2hpcC1kaGwu
ZWUwEoIQaW50cmFzaGlwLWRobC5maTASghBpbnRyYXNoaXAtZGhsLmdyMBKCEGlu
dHJhc2hpcC1kaGwuaWUwEoIQaW50cmFzaGlwLWRobC5sdDASghBpbnRyYXNoaXAt
ZGhsLmx1MBKCEGludHJhc2hpcC1kaGwubHYwEoIQaW50cmFzaGlwLWRobC5ubDAP
gg1sZXNlcmtpb3NrLmRlMBGCD2xlc2Vyc2VydmljZS5kZTAYghZsZXNlcnNlcnZp
Y2UtbWVkaWEuZGUgMCGCH2xlc2Vyc2VydmljZS1zaWNoZXJoZWl0c2Fiby5kZSAw
DoIMbGV0dGVybmV0LmRlMBGCD2xldHRlcm5ldC1iby5kZTATghFsZXR0ZXJuZXQt
cmVmLmRlIDATghFtYWlsaW5nZmFjdG9yeS5kZTAOggxtZWRpYW1haWwuZGUwDoIM
bWVpbnBha2V0LmRlMAuCCW1yc2MuaW5mbzASghBteWJpbGwuZGhsLmNvLmlsMBeC
FW9ubGluZWZyYW5raWVydW5nLmRlIDAQgg5wYWNrc3RhdGlvbi5kZTAKgghwYWtl
dC5kZTAggh5wYXJ0bmVycG9ydGFsLWRldXRzY2hlcG9zdC5kZSAwFIIScG9ydG9r
YWxrdWxhdG9yLmRlMAmCB3Bvc3QuZGUwD4INcG9zdGFkcmVzcy5kZTAPgg1wb3N0
ZGlyZWt0LmRlMBOCEXBvc3RvZmZpY2VzaG9wLmRlMBaCFHBvc3QtcGFydG5lci1z
aG9wLmRlMA2CC3ByaW50Y29tLmRlMA+CDXByaW50dHJhY2suZGUwE4IRcmVudGVu
c2VydmljZS5jb20wEoIQc2NocmVpYmNlbnRlci5kZTAdghtzbWFydHNlbnNvci10
ZW1wZXJhdHVyZS5uZXQwFIISc29jaWFsbWVtb3JpZXMuY29tMA6CDHRlbGVncmFt
bS5kZTAIggZ2Z2wubmwwCYIHd2xkcy5kZTAYghZ3b3JsZHNlcnZpY2VjZW50cmUu
Y29tMA6CDGJsdWVkYXJ0LmNvbTAOggxkaGwtZXNoaXAubmwwD4INZGhsLWV0cmFj
ay5ubDAWghRkaGwtaW50ZXJuZXR0cmFjay5ubDAWghRkaGxyZXRvdXJvcGRyYWNo
dC5ubDARgg9kaGxzcGVlZHBhY2suYmUwEYIPZGhsLXRyYWNrbmV0Lm5sMBKCEGlu
dHJhc2hpcC1kaGwuaHUwEYIPc2VydmljZXBvaW50LnNlMA2CC3VtemllaGVuLmRl
MFmkVzBVMQswCQYDVQQGEwJERTEcMBoGA1UECBMTTm9yZHJoZWluLVdlc3RmYWxl
bjENMAsGA1UEBxMEQm9ubjEZMBcGA1UEChMQRGV1dHNjaGUgUG9zdCBBRzBWpFQw
UjELMAkGA1UEBhMCREUxHDAaBgNVBAgTE05vcmRyaGVpbi1XZXN0ZmFsZW4xDTAL
BgNVBAcTBEJvbm4xFjAUBgNVBAoTDURldXRzY2hlIFBvc3ShMDAKhwgAAAAAAAAA
ADAihyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAnBgNVHSUEIDAe
BggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMJMD0GA1UdHwQ2MDQwMqAwoC6G
LGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvdHJ1c3Ryb290ZzIuY3JsMIGE
BggrBgEFBQcBAQR4MHYwMwYIKwYBBQUHMAGGJ2h0dHA6Ly9vY3NwMi5nbG9iYWxz
aWduLmNvbS90cnVzdHJvb3RnMjA/BggrBgEFBQcwAoYzaHR0cDovL3NlY3VyZS5n
bG9iYWxzaWduLmNvbS9jYWNlcnQvdHJ1c3Ryb290ZzIuY3J0MB0GA1UdDgQWBBTI
AwLewLGrg8Ue/gf3eL3lgwSIfTAfBgNVHSMEGDAWgBQU9uWLMbZFgEpMbfzCh4nK
NsOQYjANBgkqhkiG9w0BAQUFAAOCAQEAkc0t50j0hsGe6IcFlXh7oX4HAcEbai3z
mcQTwcGcmpFZQWiSKM8BPsdp502QSANyYf5IfywVUN+X22JIumb/Rkl0GGSZMGh/
a3yvVK0iBfNHxSr9EoE8TxTMlzT4WhQAC0QZ+SHts49d3haFohkM04q4zHKl5zq/
apDigTUgPf7MwT87LfqTxhbJa4TwoWBgyVqSs1zS9noGcbjUMSEsTcRjeM9GVs2v
0ZOkDABycGEQ40peJTGJZAM2XGdKAq5Tlt++8yaMY3FUzhWS00JW8ff90gMtIxgP
Vpmh/e9DOQifITme0e6n12q7yO9zhGwNLf5SsdR+JsLLW0VnRWvPjg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEXTCCA0WgAwIBAgILBAAAAAABNuk6OrMwDQYJKoZIhvcNAQEFBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xMjA0MjUxMTAw
MDBaFw0yNzA0MjUxMTAwMDBaMFwxCzAJBgNVBAYTAkJFMRUwEwYDVQQLEwxUcnVz
dGVkIFJvb3QxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExGzAZBgNVBAMTElRy
dXN0ZWQgUm9vdCBDQSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AKyuvqrtcMr7g7EuNbu4sKwxM127UsCmx1RxbxxgcArGS7rjiefpBH/w4LYrymjf
vcw1ueyMNoqLo9nJMz/ORXupb35NNfE667prQYHa+tTjl1IiKpB7QUwt3wXPuTMF
Ja1tXtjKzkqJyuJlNuPKT76HcjgNqgV1s9qG44MD5I2JvI12du8zI1bgdQ+l/KsX
kTfbGjUvhOLOlVNWVQDpL+YMIrGqgBYxy5TUNgrAcRtwpNdS2KkF5otSmMweVb5k
hoUVv3u8UxQH/WWbNhHq1RrIlg/0rBUfi/ziShYFSB7U+aLx5DxPphTFBiDquQGp
tB+FC4JvnukDStFihZCZ1R8CAwEAAaOCASMwggEfMA4GA1UdDwEB/wQEAwIBBjAP
BgNVHRMBAf8EBTADAQH/MEcGA1UdIARAMD4wPAYEVR0gADA0MDIGCCsGAQUFBwIB
FiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAdBgNVHQ4E
FgQUFPblizG2RYBKTG38woeJyjbDkGIwMwYDVR0fBCwwKjAooCagJIYiaHR0cDov
L2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDA+BggrBgEFBQcBAQQyMDAwLgYI
KwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjEwHwYD
VR0jBBgwFoAUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB
AL7IG0l+k4LkcpI+a/kvZsSRwSM4uA6zGX34e78A2oytr8RG8bJwVb8+AHMUD+Xe
2kYdh/Uj/waQXfqR0OgxQXL9Ct4ZM+JlR1avsNKXWL5AwYXAXCOB3J5PW2XOck7H
Zw0vRbGQhjWjQx+B4KOUFg1b3ov/z6Xkr3yaCfRQhXh7KC0Bc0RXPPG5Nv5lCW+z
tbbg0zMm3kyfQITRusMSg6IBsDJqOnjaiaKQRcXiD0Sk43ZXb2bUKMxC7+Td3QL4
RyHcWJbQ7YylLTS/x+jxWIcOQ0oO5/54t5PTQ14neYhOz9x4gUk2AYAW6d1vePwb
hcC8roQwkHT7HvfYBoc74FM=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAw
MDBaFw0yODAxMjgxMjAwMDBaMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT
aWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaDuaZ
jc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6NiY6arymAZavp
xy0Sy6scTHAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp
1Wrjsok6Vjk4bwY8iGlbKk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdG
snUOhugZitVtbNV4FpWi6cgKOOvyJBNPc1STE4U6G7weNLWLBYy5d4ux2x8gkasJ
U26Qzns3dLlwR5EiUWMWea6xrkEmCMgZK9FGqkjWZCrXgzT/LCrBbBlDSgeF59N8
9iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E
BTADAQH/MB0GA1UdDgQWBBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0B
AQUFAAOCAQEA1nPnfE920I2/7LqivjTFKDK1fPxsnCwrvQmeU79rXqoRSLblCKOz
yj1hTdNGCbM+w6DjY1Ub8rrvrTnhQ7k4o+YviiY776BQVvnGCv04zcQLcFGUl5gE
38NflNUVyRRBnMRddWQVDf9VMOyGj/8N7yy5Y0b2qvzfvGn9LhJIZJrglfCm7ymP
AbEVtQwdpf5pLGkkeB6zpxxxYu7KyJesF12KwvhHhm4qxFYxldBniYUr+WymXUad
DKqC5JlR3XC321Y9YeRq4VzW9v493kHMB65jUr9TU/Qr6cf9tveCX4XSQRjbgbME
HMUfpIBvFSDJ3gyICh3WZlXi/EjJKSZp4A==
-----END CERTIFICATE-----

[Peter Gutmann]

Kurt Roeckx <ku...@roeckx.be> writes:

>The site hasn't been fixed, at least not for me.

Ah, both Firefox and IE were connecting, but that was because the HTTPS got
redirected to plain HTTP, and any of the links to HTTPS sites that I could
find on the site led to a bewildering array of affiliated sites that all went
back to Comodo roots.

After some poking around I managed to find the same certs at
postofficeshop.de, but Firefox still connects to that.

>Here are the certificates I get:

Thanks! Wow, what a mess, theres:

018 45: SEQUENCE {
1020 37: OBJECT IDENTIFIER '1 3 6 1 4 1 311 21 8 3675690 6234259 10436751 12227305 62135 141 959321 10252252'
: Error: OID contains random garbage.
1059 1: INTEGER 100
1062 1: INTEGER 6
: }

(that's one of Microsoft's "encode random noise and call it an OID), and then:

1209 68: SEQUENCE {
1211 9: OBJECT IDENTIFIER
: sMIMECapabilities (1 2 840 113549 1 9 15)
1222 55: OCTET STRING, encapsulates {

for what is explicitly a TLS server cert:

1074 20: SEQUENCE {
1076 8: OBJECT IDENTIFIER
: clientAuth (1 3 6 1 5 5 7 3 2)
1086 8: OBJECT IDENTIFIER
: serverAuth (1 3 6 1 5 5 7 3 1)
: }
: }

Oh yeah, and the S/MIME implementation that their TLS server runs advertises:

1226 14: SEQUENCE {
1228 8: OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
1238 2: INTEGER 128
: }
1242 14: SEQUENCE {
1244 8: OBJECT IDENTIFIER rc4 (1 2 840 113549 3 4)
1254 2: INTEGER 128
: }
1258 7: SEQUENCE {
1260 5: OBJECT IDENTIFIER desCBC (1 3 14 3 2 7)
: }

because someone has to keep all those 1970s and 1980s ciphers alive somewhere.

Then the next cert has:

710 2683: SEQUENCE {
714 3: OBJECT IDENTIFIER nameConstraints (2 5 29 30)
719 2674: OCTET STRING, encapsulates {
723 2670: SEQUENCE {
727 2616: [0] {
731 17: SEQUENCE {
733 15: [2] 'adressdialog.de'
: }
750 20: SEQUENCE {
752 18: [2] 'adress-research.de'
: }
[on and on for hundreds of lines]

and:

3347 48: [1] {
3349 10: SEQUENCE {
3351 8: [7] 00 00 00 00 00 00 00 00
: }
3361 34: SEQUENCE {
3363 32: [7]
: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
: }
: }
: }

The recent CNNIC discussion mentioned the fact that trusted CAs shouldn't be
allowed to issue unconstrained certs for intermediate CAs. Perhaps we need to
introduce requirements for drug-testing intermediates as well.

Peter.

[Erwann Abalea]

Le samedi 11 avril 2015 16:30:50 UTC+2, Peter Gutmann a écrit :
> Kurt Roeckx <ku...@roeckx.be> writes:
>
> >The site hasn't been fixed, at least not for me.
>
> Ah, both Firefox and IE were connecting, but that was because the HTTPS got
> redirected to plain HTTP, and any of the links to HTTPS sites that I could
> find on the site led to a bewildering array of affiliated sites that all went
> back to Comodo roots.
>
> After some poking around I managed to find the same certs at
> postofficeshop.de, but Firefox still connects to that.
>
> >Here are the certificates I get:
>
> Thanks! Wow, what a mess, theres:
>
> 018 45: SEQUENCE {
> 1020 37: OBJECT IDENTIFIER '1 3 6 1 4 1 311 21 8 3675690 6234259 10436751 12227305 62135 141 959321 10252252'
> : Error: OID contains random garbage.
> 1059 1: INTEGER 100
> 1062 1: INTEGER 6
> : }
>
> (that's one of Microsoft's "encode random noise and call it an OID), and then:

That's really an OID, in the Microsoft arc. I don't know what triggered the "Error: OID contains random garbage" message, but it's wrong. This OID is correctly encoded, the fact that it contains somewhat random looking integers isn't an error.

>
> 1209 68: SEQUENCE {
> 1211 9: OBJECT IDENTIFIER
> : sMIMECapabilities (1 2 840 113549 1 9 15)
> 1222 55: OCTET STRING, encapsulates {
>
> for what is explicitly a TLS server cert:

That could fall under CABF BR Appendix B (4) (a) rule.

> Then the next cert has:
>
> 710 2683: SEQUENCE {
> 714 3: OBJECT IDENTIFIER nameConstraints (2 5 29 30)
> 719 2674: OCTET STRING, encapsulates {
> 723 2670: SEQUENCE {
> 727 2616: [0] {
> 731 17: SEQUENCE {
> 733 15: [2] 'adressdialog.de'
> : }
> 750 20: SEQUENCE {
> 752 18: [2] 'adress-research.de'
> : }
> [on and on for hundreds of lines]

All the domains they have demonstrated ownership for, or have been granted by their respective owner.

No upper limit is imposed by the standards. It's their own choice to either choose between having an inflated CA certificate (3.9k, not that much) or supporting an yearly audit.

> and:
>
> 3347 48: [1] {
> 3349 10: SEQUENCE {
> 3351 8: [7] 00 00 00 00 00 00 00 00
> : }
> 3361 34: SEQUENCE {
> 3363 32: [7]
> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> : }
> : }
> : }

This is required by the CABF BR. Entire IPv4 and IPv6 scope in the excluded branch.


The heading space character in the CN shouldn't have caused the "sec_error_bad_der" error. And a properly written TLS client should ignore the content of the CN if a SAN is present.
Maybe one of those certificates is really badly DER-encoded?

[Peter Gutmann]

Erwann Abalea <eab...@gmail.com> writes:

>That's really an OID, in the Microsoft arc. I don't know what triggered the
>"Error: OID contains random garbage" message,

Uhh, the fact that it contains random garbage encoded as an OID?

>This OID is correctly encoded, the fact that it contains somewhat random
>looking integers isn't an error

Taking Microsoft's own words (from
https://msdn.microsoft.com/en-us/library/windows/desktop/bb540791%28v=vs.85%29.aspx):

The individual elements in the string, separated by periods, represent the
arcs and leaves in a registration authority tree that uniquely identifies
the object and the organization that registered it.

could you perhaps explain to the class which arcs and leaves in a registration
authority tree [...] 3675690 6234259 10436751 12227305 62135 141 959321
10252252 represent?

>This is required by the CABF BR.

If this gibberish is required by the BR then there's an awful lot of
noncompliant certs out there. Pretty much all of them, I'd say.

>That could fall under CABF BR Appendix B (4) (a) rule.

Even if I hold the BR doc sideways and squint at it, I still can't see where
in B (4) it says the CA has to include an S/MIME extension for 1970s and 1980s
crypto algorithms in a TLS server cert. In particular the wording:

The CA SHALL NOT issue a Certificate that contains [...] unless the CA is
aware of a reason for including the data in the Certificate.

CAs SHALL NOT issue a Certificate with [...] unless the Applicant can
otherwise demonstrate the right to assert the data in a public context;

basically says "CAs SHALL NOT do X except that they can if they want".

>That could fall under CABF BR Appendix B (4) (a) rule.

>No upper limit is imposed by the standards.

There's also no law specifically saying that you're not allowed to stagger
around in public complaining that the sun is too loud and warning people about
the ice weasels, but that doesn't mean that it's not a sign that something's
gone seriously wrong somewhere.

Peter.

[Erwann Abalea]

Bonjour Peter,

Le dimanche 12 avril 2015 09:32:40 UTC+2, Peter Gutmann a écrit :
> Erwann Abalea <eab...@gmail.com> writes:
>
> >That's really an OID, in the Microsoft arc. I don't know what triggered the
> >"Error: OID contains random garbage" message,
>
> Uhh, the fact that it contains random garbage encoded as an OID?

Well, since a set of numbers that has no clearly identifiable meaning for an outside user can reasonably be considered as "random", the "OID contains random garbage" part of the message is right. But that doesn't mean it's an error.

> >This OID is correctly encoded, the fact that it contains somewhat random
> >looking integers isn't an error
>
> Taking Microsoft's own words (from
> https://msdn.microsoft.com/en-us/library/windows/desktop/bb540791%28v=vs.85%29.aspx):
>
> The individual elements in the string, separated by periods, represent the
> arcs and leaves in a registration authority tree that uniquely identifies
> the object and the organization that registered it.
>
> could you perhaps explain to the class which arcs and leaves in a registration
> authority tree [...] 3675690 6234259 10436751 12227305 62135 141 959321
> 10252252 represent?

Sure. The 1.3.6.1.4.1.311 is Microsoft's OID arc. 1...311.21 is declared as "Microsoft CertSrv Infrastructure", and 1...311.21.8 as "The root oid for all enterprise specific oids".

The rest may be known only by the Registration Authority, the publication of the complete arc isn't mandatory. Not knowing the exact meaning of this suite of integers doesn't mean this meaning doesn't exist. Microsoft may really maintain a complicated OID tree for that purpose, who knows? And even if those number are randomly allocated, they still can have a meaning, and the OID can still identify something.

[2 SEQUENCE full of zeros]

> >This is required by the CABF BR.
>
> If this gibberish is required by the BR then there's an awful lot of
> noncompliant certs out there. Pretty much all of them, I'd say.

This is required for technically constrained CAs not allowed to issue certificates with an iPAddress. See CABF BR section 9.7.
The fact that this encoding is full of zeroes isn't a Mozilla/CABF/GlobalSign issue.

A technically constrained CA allowed to issue certificates with an iPAddress won't have this part. And of course a non technically constrained CA won't have this entire extension.

[S/MIME capabilities extension]

> >That could fall under CABF BR Appendix B (4) (a) rule.
>
> Even if I hold the BR doc sideways and squint at it, I still can't see where
> in B (4) it says the CA has to include an S/MIME extension for 1970s and 1980s
> crypto algorithms in a TLS server cert. In particular the wording:
>
> The CA SHALL NOT issue a Certificate that contains [...] unless the CA is
> aware of a reason for including the data in the Certificate.
>
> CAs SHALL NOT issue a Certificate with [...] unless the Applicant can
> otherwise demonstrate the right to assert the data in a public context;
>
> basically says "CAs SHALL NOT do X except that they can if they want".

I wasn't saying that the CA has to, or could include such an extension. Quite the contrary, in fact.
Declaring S/MIME capabilities for a TLS server cert is inconsistent.

> >No upper limit is imposed by the standards.
>
> There's also no law specifically saying that you're not allowed to stagger
> around in public complaining that the sun is too loud and warning people about
> the ice weasels, but that doesn't mean that it's not a sign that something's
> gone seriously wrong somewhere.

(That may change in Florida, where officials are not allowed to use the terms "global warming", or "climate change")

Ok. Why should the CABF put a limit (on the number of domains) above which the CA MUST either:
- have several CA certificates, or
- pass a yearly audit
(by "why", I'm questioning the security benefit of such a restriction on the constraint)

Where should the CABF set the limit to?