Closed Bug 458745 Opened 16 years ago Closed 16 years ago

UTF-8 Fields in Cert treated as ASCII (sometimes)

Categories

(Core :: Security: PSM, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: johnath, Assigned: KaiE)

References

Details

It's possible the problem here lies with the certificate itself, and not our handling of it, but I couldn't rule that out, so I figured it was worth tracking.

https://www.joes-ssl.com/  is a site with an Org name which is trying to be UTF-8 but which we are rendering (in the cert viewer, as well as Larry) as garbled ascii text.

Server certificate:
-----BEGIN CERTIFICATE-----
MIIFqzCCBJOgAwIBAgIQep3VURocjw83tm2Ke15dCTANBgkqhkiG9w0BAQUFADCB
ujELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNjE0MDIGA1UEAxMr
VmVyaVNpZ24gQ2xhc3MgMyBFeHRlbmRlZCBWYWxpZGF0aW9uIFNTTCBDQTAeFw0w
ODA5MDkwMDAwMDBaFw0wOTA5MDkyMzU5NTlaMIIBGzETMBEGCysGAQQBgjc8AgED
EwJKUDEWMBQGCysGAQQBgjc8AgECFAVPc2FrYTEbMBkGA1UEDxMSVjEuMCwgQ2xh
dXNlIDUuKGIpMRcwFQYDVQQFEw4xMjk5LTAxLTExMzIxNDELMAkGA1UEBhMCSlAx
DjAMBgNVBAgUBU9zYWthMRIwEAYDVQQHFAlPc2FrYS1zaGkxNTAzBgNVBAoULOag
quW8j+S8muekvkpvZSdz44Km44Kn44OW44Ob44K544OG44Kj44Oz44KwMTMwMQYD
VQQLFCpUZXJtcyBvZiB1c2UgYXQgd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUx
GTAXBgNVBAMUEHd3dy5qb2VzLXNzbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALSs0Jh96lO0vGgyX/SA9FSkG+PSDtQQ1K4OxapZ7Vwo9cWFvYcg0UX8
IZ3YmCHMsPM6DYYhUvIyACghwM05wf4/cnwKWGzAWbiV11svUfO+vHxNDsRdbzt1
Se8EeDypw0MxGP9cKyL6ZGikU6T4eLtrQtrByrzLN+pVYO+w/I1xAgMBAAGjggHL
MIIBxzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDBCBgNVHR8EOzA5MDegNaAzhjFo
dHRwOi8vRVZTZWN1cmUtY3JsLnZlcmlzaWduLmNvbS9FVlNlY3VyZTIwMDYuY3Js
MEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwYwKjAoBggrBgEFBQcCARYcaHR0cHM6
Ly93d3cudmVyaXNpZ24uY29tL2NwczAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYB
BQUHAwIwHwYDVR0jBBgwFoAU/IpQup65JVp7VYVPlQBjj+lYa0MwcwYIKwYBBQUH
AQEEZzBlMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wPQYI
KwYBBQUHMAKGMWh0dHA6Ly9FVlNlY3VyZS1haWEudmVyaXNpZ24uY29tL0VWU2Vj
dXJlMjAwNi5jZXIwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lm
MCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xv
Z28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMA0GCSqGSIb3DQEBBQUAA4IBAQBs
WYQkVOVvRIfENj5dicPifYxs1Ck+xR58AT+OMAeL+Y9fayECvm1phAbVMAKavNPv
HIEnZkvh99tAPrNwyZqT8hpYXqE05HBD1qqs5D6O+M/n84yde0kjOUdYfyIbszec
ojvfQ6b4R73nm10MDm665Ok6o4VvZvcdCIXJ8eXQQ/NbIN4v/kpfPAKRB88ltKp3
WvhVCUNAZO94ePg81a7yVETPwAkf+kzesuDu2gunv0U4c9CApGA6uMJ6cz7ud8OX
FSXe3oxCTS1eb1V5ZPu9+lc1qLCDhNEV5oDtJWas+3YPcQO3z8nSVCFY53ckNBi5
e1UpQyGcck3eL3Wfa8G9
-----END CERTIFICATE-----

By contrast, https://www.myssl.cn/ is also presenting a cert with a UTF-8 O= field, and this one is rendered properly.

-----BEGIN CERTIFICATE-----
MIIE3zCCA8egAwIBAgICATUwDQYJKoZIhvcNAQEFBQAwgYUxCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxHZW9UcnVzdCBJbmMxMTAvBgNVBAsTKFNlZSB3d3cuZ2VvdHJ1
c3QuY29tL3Jlc291cmNlcy9jcHMgKGMpMDYxLDAqBgNVBAMTI0dlb1RydXN0IEV4
dGVuZGVkIFZhbGlkYXRpb24gU1NMIENBMB4XDTA4MDcxMDAxNTU1OVoXDTA5MDkw
OTAxNTU1OVowgdkxGzAZBgNVBA8TElYxLjAsIENsYXVzZSA1LihiKTETMBEGCysG
AQQBgjc8AgEDEwJDTjEWMBQGA1UEBRMNMzEwMTE0MjAyMTk3MjELMAkGA1UEBhMC
Q04xETAPBgNVBAgcCAAATgoAAG13MREwDwYDVQQHHAgAAE4KAABtdzExMC8GA1UE
ChwoAABOCgAAbXcAAI/FAACQGgAAedEAAGKAAABnCQAAllAAAFFsAABT+DEQMA4G
A1UECxMHSVQgRGVwdDEVMBMGA1UEAxMMd3d3Lm15c3NsLmNuMIGfMA0GCSqGSIb3
DQEBAQUAA4GNADCBiQKBgQC5Q/N9v2zaIDlm/cVk0mNM2huf7DHyh9h793uC9Vgc
bmxVtw2xQAAsJRmig6YVvMEJrhVyjMiBcCiyyFkEbuoFFknuZPlVbu8cnLto7dPo
GQ6T14dfWsuKhUxQswIFAZx4+QY7m98r97Jzf8//DIneyYesCjdwzqjlboQyyysI
3wIDAQABo4IBhTCCAYEwDgYDVR0PAQH/BAQDAgWgMEsGA1UdIAREMEIwQAYJKwYB
BAHwIgEGMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly93d3cuZ2VvdHJ1c3QuY29tL3Jl
c291cmNlcy9jcHMwQgYDVR0fBDswOTA3oDWgM4YxaHR0cDovL0VWU1NMLWNybC5n
ZW90cnVzdC5jb20vY3Jscy9ndGV4dHZhbGNhLmNybDAfBgNVHSMEGDAWgBQoxOuP
8V95kKMrVcNWTn1rU3IsGDBuBggrBgEFBQcBAQRiMGAwKgYIKwYBBQUHMAGGHmh0
dHA6Ly9FVlNTTC1vY3NwLmdlb3RydXN0LmNvbTAyBggrBgEFBQcwAoYmaHR0cDov
L0VWU1NMLWFpYS5nZW90cnVzdC5jb20vZXZjYS5jcnQwHQYDVR0lBBYwFAYIKwYB
BQUHAwEGCCsGAQUFBwMCMA8GA1UdEwEB/wQFMAMCAQAwHQYDVR0OBBYEFAgSH9Vz
ZDXQ3Cm4MtIHSPaNQd6yMA0GCSqGSIb3DQEBBQUAA4IBAQBvcPsdStmhPh+c/3d+
JokpB0LAg7IMkxHve2u2PkxZfFOBRRYjgHSstJuxIQCKsyqGOT3kIJIngVAU4stn
AkAYIV/u+48Uq2tVsh08UqVxg69QZI1WJwB9GL70f2mdn184vb8lH825zLitThQv
LBlKLT8NgWbPseLjd/9fiOReFG+2hHE9SGD/KZGypTZr6xrEsgnnz6bMZLMhw6lZ
Y4rKQyRgEk8S4QWNTvAHIDNBDawYNkQrv/vaS0IOxyZ7wxcOESjsjsWjvm8jhbVF
tBs1qUswE3ur80fKrMB8HVZJ09NPM2CL19oy+SxS+xK9YrzZ4i+wD7WHNq8EbNut
ppk1
-----END CERTIFICATE-----

The fact that we do the "right thing" in some cases makes me wonder whether the certificate is the problem here.  I do notice that the joes-ssl cert mixes UTF-8 and Ascii (note "Joe's" in the middle of the O string) which may be part of the problem.

Nevertheless, IE is displaying both O fields properly, so if it is an encoding problem, we should be able to provide CAs with a clear answer as to what the problem is, and if it is a problem on our end, well then I guess we should fix it, since sites with this problem are live out there.
(In reply to comment #0)
> Nevertheless, IE is displaying both O fields properly, so if it is an encoding
> problem, we should be able to provide CAs with a clear answer as to what the
> problem is

The www.joes-ssl.com certificate has an organizationName RDN whose encoding is bogus - it's using TeletexString but apparently tries to use characters which are definitely not part of this character set.

The one for www.myssl.cn looks better encoding-wise, though it's still not compliant with RFC 5280 - which requires the use of either PrintableString or UTF8String (but ST, L and O are encoded as UniversalString in this certificate).

Suggested resolution: INVALID.
Thanks for the prompt response, Kaspar.  The original reporter confirms that this is enough to conclude that the problem is on their end.  Resolving -> INVALID.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
(In reply to comment #1)
> The www.joes-ssl.com certificate has an organizationName RDN whose encoding is
> bogus - it's using TeletexString but apparently tries to use characters which
> are definitely not part of this character set.

That wording is probably a bit too apodictic, when reading it again right now. According to table 6 in the ITU-T recommendation X.680 (the specification of ASN.1), the TeletexString/T61String encoding allows a fairly large number of different character sets to be used, including some of the multi-byte character sets from the "ISO International Register of Coded Character Sets to be used with Escape Sequences" - see http://www.itscj.ipsj.or.jp/ISO-IR/2-4.htm.

The issue with the www.joes-ssl.com certificate is mainly that it doesn't use an escape sequence to specify that it's using one of the JIS encodings... and while the MS CryptoAPI apparently uses heuristics for figuring out the correct set, NSS always treats TeletexStrings as ISO-8859-1 strings (http://mxr.mozilla.org/mozilla/source/security/nss/lib/certdb/secname.c?mark=654-661#643).

Which means, after all, that this bug might also be resolved as WONTFIX. In any case, using either UniversalString or TeletexString is deprecated as per RFC 5280 ("SHOULD NOT be used for certificates for new subjects"), and switching to UTF8String is definitely the preferred solution.
You need to log in before you can comment on or make changes to this bug.