Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 715969 ERR_SSL_SERVER_CERT_BAD_FORMAT without explanation
Starred by 6 users Reported by ontech...@gmail.com, Apr 27 Back to list
Status: Duplicate
Merged: issue 717905
Owner:
Closed: May 2
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment
Chrome Version       : 59.0.3071.25 dev
OS Version: OS X 10.12.4
URLs (if applicable) : https://orf.at/

What steps will reproduce the problem?
1. navigate to https://orf.at/

What is the expected result?
redirect to http://orf.at/

What happens instead of that?
error page saying:
"This site can’t provide a secure connection
orf.at doesn't adhere to security standards.
ERR_SSL_SERVER_CERT_BAD_FORMAT"

Please provide any additional information below. Attach a screenshot if
possible.

Did work before up to including Chrome 58. No problem on Windows, only on macOS, reproduced with current dev (59) and canary (60). If there really is a problem with the certificate, it would be valuable to know what it is and why and how to fix it.


 
https-orf.at.png
102 KB View Download
https-orf.at-about.png
91.1 KB View Download
Components: Internals>Network>Certificate
Cc: eroman@chromium.org rsleevi@chromium.org
Owner: mattm@chromium.org
The cert subject's organizationName is tagged as TeletexString, and contains the character code 214. It appears that it has the issue of actually being Latin1 text and not actually a TeletexString (214 in latin1 is Ö). Ideally this should be encoded using UTF8String which is a well specified and well supported standard.  (RFC 5280 allows TeletexString only for backwards compatability and handling TeletexString is optional.)

Due to the complexity & underspecified nature of the real TeletexString, as well as the old practice of just sticking Latin1 strings in fields marked as TeletexString, the change crrev.com/4cede8d39db10321b053c0d9776cf6b23f290310,  takes a conservative approach to handling TeletexString, only allowing the ASCII subset.

Ryan/Eric: do you think we should be more forgiving when receiving certs like that? (This comes up because X509Certificate class parses the Subject and Issuer fields into CertPrincipal objects.)
To expand a bit on the last comment:

Ideally we shouldn't care about the encoding here just to connect to a site.

Perhaps CertPrincipal objects should just be removed from X509Certificate, and the use points could be changed to do parsing as needed. Then any encoding errors could be handled only when they matter, and in a more context-appropriate fashion.  However, that would be a large change.

Alternately, CertPrincipal could do something cheap like hexlify any undecodable strings, but this would probably require some digging to verify if it might cause any issues with the ways CertPrincipal is currently used.

Or, we could just interpret teletexstring as latin1, but that is ugly and not standard compliant.. (Is there anyone who actually uses real correctly-encoded non-ascii teletexstrings?)
Cc: elawre...@chromium.org
Components: UI>Browser>Omnibox>SecurityIndicators
I don't, considering that CertPrincipal is used to populate the security UI. I think the last thing we'd want is to accept a connection but not be able to display certificate information about.

I'm gonna tag the UI>Browser>Omnibox>SecurityIndicators folks, to see how they feel about allowing certs they wouldn't be able to parse.
Components: -UI>Browser>Omnibox>SecurityIndicators
Labels: team-se
How much of an edge cases is this/do we have stats?

If it doesn't happen often, I don't think we should accommodate it – we'd rather show fewer bypassable interstitials anyhow.
This isn't a true a/b comparison, and may include other issues that cause the same error, but UMA stats for mac versions before the change vs after the change: SSL_SERVER_CERT_BAD_FORMAT goes from 0.00% to 0.14%

And the alternate approach wouldn't be an interstitial, but to accept the connection as valid. (Cert verification doesn't actually need to decode these strings, it can just do plain byte comparisons for any unsupported string types.) But then there would be the question of what to do if we want to display that string in the UI somewhere...
Components: UI>Browser>Omnibox>SecurityIndicators
Just to clarify on Matt's Comment #6 - There were several other RFC compliance bits that came from 5280 here, this is just one of them (thus not the only source of errors). I suspect the majority of the errors may come from enforcing that extensions are only part of v3 certs, whereas poorly configured OpenSSL tools (... including older versions of pyOpenSSL) default to v1 even when adding extensions. So the error cause is not *strictly* this, and reverting the UI bit won't see it return to 0.00%.

Re: Comment #5: What's the team-se label? I've readded the component, because the PageInfo verbose state (where it shows permissions) makes use of this field, and we're specifically asking for advice on what implications it would have to have a certificate accepted where this field could not be displayed.
Labels: -team-se Team-Security-UX
`team-se` was meant to be `Team-Security-UX`. (*shakes fist at Monorail, then feels silly for not noticing*)

Wouldn't the verbose state just show "Not secure"?
If so, where is the field actually displayed? Security panel? Certificate viewer? And can I test how the UI would look in this case?
@Comment 8: Apologies that it's not clearer.

Currently, we reject these certificates as BAD_FORMAT. When we do that, there's no additional parsing for any form of security UI since, well, it's bad format.

The question is whether to accept this (bad format) since it's not strictly necessarily for the domain validation portion. If we do that, then it would say "Secure" - and the *good* information does make use of the subject/issuer. This is the change elawrence@ has been working on to add the View Certificate link to the PIB when you click it, or to DevTools Security Panel, or, if there _were_ an issue with the certificate name, in the interstitial. I tried to go for the lowest hanging fruit, but as you can see, it's fairly cross-component cutting in the Security-facing strings.

The current process has zero negative effect - we reject it outright. Matt was asking about making it more lenient, but that would mean that creating a CertPrincipal would fail, and the CertPrincipal is the driver for all of those UI aspects.
This HTTPS site seems to work on Windows-- is the limitation Mac specific?

Are certificates encoded this way in violation of the baseline requirements?

To me, the proposal in #3 sounds reasonable:

"Alternately, CertPrincipal could do something cheap like hexlify any undecodable strings"

Why? Because a certificate's subject field could contain all manner of bogus text anyway, and now that we're not using that text to find the CN for hostname verification, it seems harmless enough to allow bogus text that we generate when we parse bogus encoding. So long as we include the characters in some form (\dxD6), it seems like the actual spoofing potential here is essentially nil. 
They work on Windows because we haven't switched parsers yet.

Considering that there's no (public) consistent documents for T61String, arguably, they're in violation. Certainly of a should, certainly of best practice.

I'd certainly prefer that we not accept these certs (which are a minimal population and outside the bounds of RFC 5280-mandated support, given the above lack of public docs).
Re #11: Unless such certificates are very common, I think the Enamel team is unlikely to object to your proposal (blocking these certificates).

This issue might be dupeable to Issue 504499 ("Chrome should show helpful information on Net errors"), although I don't think that bug is likely to get much attention in the near future. 
Mergedinto: 504499
Status: Duplicate
Re #11: X.690 has a clear public definition for this string type.  It is a string that follows ISO/IEC 2022 which has character set 102 in G0, 106 in C0, and 107 in C1.  

https://www.itscj.ipsj.or.jp/iso-ir/102.pdf
https://www.itscj.ipsj.or.jp/iso-ir/106.pdf
https://www.itscj.ipsj.or.jp/iso-ir/107.pdf

together define the valid code points.  Note that X.690 specifies that the "change typewriter ball" escape sequences are allowed in these strings, so the presence of a byte with value 0x1B indicates that more complex processing is required.
It seems Entrust has issued several certs with non-ASCII characters in TeletexString:
https://crt.sh/?cablint=217&minNotBefore=2016-01-01
https://crt.sh/?caid=1586&opt=cablint&minNotBefore=2016-01-01

Apparently they had a bug in their workflow, see https://bugzilla.mozilla.org/show_bug.cgi?id=1268225

The last buggy cert was issued April 2016.
Project Member Comment 16 by bugdroid1@chromium.org, May 5
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/788812f7788c07aa58487523ec70f9e921d78543

commit 788812f7788c07aa58487523ec70f9e921d78543
Author: mattm <mattm@chromium.org>
Date: Fri May 05 23:49:09 2017

X509NameAttribute::ValueAsString: Decode TeletexString as Latin1.

BUG= 717905 , 715969 

Review-Url: https://codereview.chromium.org/2865603002
Cr-Commit-Position: refs/heads/master@{#469812}

[modify] https://crrev.com/788812f7788c07aa58487523ec70f9e921d78543/net/BUILD.gn
[modify] https://crrev.com/788812f7788c07aa58487523ec70f9e921d78543/net/cert/internal/parse_name.cc
[modify] https://crrev.com/788812f7788c07aa58487523ec70f9e921d78543/net/cert/internal/parse_name_unittest.cc
[modify] https://crrev.com/788812f7788c07aa58487523ec70f9e921d78543/net/cert/x509_certificate_unittest.cc
[add] https://crrev.com/788812f7788c07aa58487523ec70f9e921d78543/net/data/parse_certificate_unittest/subject_t61string.pem
[add] https://crrev.com/788812f7788c07aa58487523ec70f9e921d78543/net/data/parse_certificate_unittest/subject_t61string_1-32.pem
[add] https://crrev.com/788812f7788c07aa58487523ec70f9e921d78543/net/data/parse_certificate_unittest/subject_t61string_126-160.pem
[add] https://crrev.com/788812f7788c07aa58487523ec70f9e921d78543/net/data/parse_certificate_unittest/subject_t61string_actual.pem
[modify] https://crrev.com/788812f7788c07aa58487523ec70f9e921d78543/net/data/parse_certificate_unittest/v3_certificate_template.txt
[modify] https://crrev.com/788812f7788c07aa58487523ec70f9e921d78543/net/test/test_data_directory.cc
[modify] https://crrev.com/788812f7788c07aa58487523ec70f9e921d78543/net/test/test_data_directory.h

Thanks for the patch, it's already in the current Canaray (60) and I can confirm that the certificate is accepted again. Will this also be merged to the current Beta (59)?
Mergedinto: -504499 717905
Yes, about to submit the merge now. Thanks for confirming the fix.
Project Member Comment 19 by bugdroid1@chromium.org, May 8
Labels: merge-merged-3071
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8a4fb425dc1e081b5942975f0d1c852aae2819e6

commit 8a4fb425dc1e081b5942975f0d1c852aae2819e6
Author: Matt Mueller <mattm@chromium.org>
Date: Mon May 08 20:20:42 2017

X509NameAttribute::ValueAsString: Decode TeletexString as Latin1.

BUG= 717905 , 715969 

Review-Url: https://codereview.chromium.org/2865603002
Cr-Commit-Position: refs/heads/master@{#469812}
(cherry picked from commit 788812f7788c07aa58487523ec70f9e921d78543)

Review-Url: https://codereview.chromium.org/2866063003 .
Cr-Commit-Position: refs/branch-heads/3071@{#461}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/8a4fb425dc1e081b5942975f0d1c852aae2819e6/net/BUILD.gn
[modify] https://crrev.com/8a4fb425dc1e081b5942975f0d1c852aae2819e6/net/cert/internal/parse_name.cc
[modify] https://crrev.com/8a4fb425dc1e081b5942975f0d1c852aae2819e6/net/cert/internal/parse_name_unittest.cc
[modify] https://crrev.com/8a4fb425dc1e081b5942975f0d1c852aae2819e6/net/cert/x509_certificate_unittest.cc
[add] https://crrev.com/8a4fb425dc1e081b5942975f0d1c852aae2819e6/net/data/parse_certificate_unittest/subject_t61string.pem
[add] https://crrev.com/8a4fb425dc1e081b5942975f0d1c852aae2819e6/net/data/parse_certificate_unittest/subject_t61string_1-32.pem
[add] https://crrev.com/8a4fb425dc1e081b5942975f0d1c852aae2819e6/net/data/parse_certificate_unittest/subject_t61string_126-160.pem
[add] https://crrev.com/8a4fb425dc1e081b5942975f0d1c852aae2819e6/net/data/parse_certificate_unittest/subject_t61string_actual.pem
[modify] https://crrev.com/8a4fb425dc1e081b5942975f0d1c852aae2819e6/net/data/parse_certificate_unittest/v3_certificate_template.txt
[modify] https://crrev.com/8a4fb425dc1e081b5942975f0d1c852aae2819e6/net/test/test_data_directory.cc
[modify] https://crrev.com/8a4fb425dc1e081b5942975f0d1c852aae2819e6/net/test/test_data_directory.h

Hello, I have similar issue since Chrome 59.something

trying to access https://timvision.it

Issue present only on mac. Tested on (macOS 10.12.4)
Screenshot at May 12 14-36-05.png
38.7 KB View Download
Screenshot at May 12 14-36-45.png
19.9 KB View Download
The site listed in #20 does not appear to be caused by the same issue; the certificate at http://www.timvision.it/ does not contain either TeletexString fields or non-ASCII characters. I've filed  Issue 721778  to track. Thanks!
Chiming in to say that I'm similarly frustrated by not knowing exactly what it is that's wrong with my certificate. I'm on macOS 10.12.5 and Chrome 59.0.3071.86 and the certificates generated by our internal CA are now failing. The sites load fine on Firefox, Safari, and even cURL. I can regenerate our certificates and deploy them quickly, but "ERR_SSL_SERVER_CERT_BAD_FORMAT" is not helpful without knowing what it is that causes it to fail.

Here's an example certificate (none of our sites are publicly accessible):

-----BEGIN CERTIFICATE-----
MIIDqTCCApECAxAABzANBgkqhkiG9w0BAQ0FADCBlTEVMBMGA1UEChMMRmxveWQg
Q291bnR5MSMwIQYJKoZIhvcNAQkBFhRhZG1pbkBmbG95ZGNvdW50eS50djEQMA4G
A1UEBxMHQXRsYW50YTELMAkGA1UECBMCR0ExCzAJBgNVBAYTAlVTMSswKQYDVQQD
EyJGbG95ZCBDb3VudHkgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE3MDYxMjE5
Mzc0MVoXDTI3MDYxMDE5Mzc0MVowTzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkdB
MRUwEwYDVQQKEwxGbG95ZCBDb3VudHkxHDAaBgNVBAMTE2lzaXMuZmxveWRjb3Vu
dHkudHYwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzAP526v9aTDs1
lqD3fgFJjQwmrxOnuJsgmFInX5nhJSN40HBhyY/Umr8fpOhwqy95a7niUsuj1z+R
uABDooT4hLiQMga+XhBv+gVBMKwXluGt5AN4NdZu4epQDkq9lJfono3aJMJMuNa3
U0l9u0Al+3yMpU69RlhYv8QYa9o2dIoBRoIShRbkqcQEzZgAq5iiZ+kkIPxZylYI
qV1Y0tvYE3ZjfYu+5rzzCnjTpMqRWkQPgg4fXxeEOWqq5H+m1q4qYqD+ANZxQRMi
PdmzFTI3zxspifoUVR05oZCX7TUZCg7kdDcTCjItL4nvRyuolBxFQPaKqf3L/hhL
dVhK/wuFAgMBAAGjTDBKMAkGA1UdEwQCMAAwHQYDVR0OBBYEFB21abMeJNLQI3zO
Qz81VZokZi3UMB4GA1UdEQQXMBWCE2lzaXMuZmxveWRjb3VudHkudHYwDQYJKoZI
hvcNAQENBQADggEBANldYdr+y7yfKkC6Bezu1bElH03pqP1JaWDcTL+rcsc+Ltki
QCq9fIN4k8OUUJeWNDX+HLowJ5daMopvqfWzGlQx1W1PHrhQFnKMG4CwUWwT9YYE
26BDdm+rMWRvFmdb5ehAg9UeAKqP6DDuY/0GWPGT0sq8cVof0D7DQYmjQen1iZfH
A5ofKCQbjVnb74Ri760O+3M9jXpV6aJVa+2tUWKOKSNHPaJPBAxrD+L+p+MS9qxO
LNrB4MiAvlA9NEhWPg61OfPj+bw+Ab+xiKgO/BuT3LCRlfvKqnZpl0kii7hv77ys
jIZJINPPxVqC/nzxTRQq7igWXusAsjL4oB3LpT8=
-----END CERTIFICATE-----
It's a version 1 (0x0) certificate with extensions. The proper version should be version 3 (0x2).

While we're working to improve the diagnostic error reporting, note that to some extent, ERR_SSL_SERVER_CERT_BAD_FORMAT generally means 'unparseable to spec' (as this would be).
Changing the cert to version 3 did indeed fix. Thanks for pointing me in the right direction.
Comment 25 by kimnori...@gmail.com, Jul 17 (5 days ago)
Hello, I have similar issue since Chrome 59.0.3071.115
Issue present only on mac. Tested on (macOS 10.11.3)

I use ssl certificate of version 2.
I saw comment that "The proper version should be version 3 (0x2)."
Is it true that we can only use version 3 ssl certificate as these comment?


-----BEGIN CERTIFICATE-----
MIIDJjCCAg6gAwIBAQICAOIwDQYJKoZIhvcNAQELBQAwRjELMAkGA1UEBhMCS1Ix
ETAPBgNVBAoMCFBlcnNvbmFsMRUwEwYDVQQLDAxTaWduS29yZWEgTkExDTALBgNV
BAMMBFJvb3QwHhcNMTcwNzEzMDU0MjIxWhcNMTgwNzEzMDU0MjIxWjBGMQswCQYD
VQQGEwJLUjERMA8GA1UECgwIUGVyc29uYWwxFTATBgNVBAsMDFNpZ25Lb3JlYSBO
QTENMAsGA1UEAwwEUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
ANHPO+KHQJlNOvaN8hjIivqqZqf6thFy8CeKZjx8yy7Y7U1Uia+cHPDiR2tTA2Gm
jK7RiNH2Fiz2NudVseuhoigBIr7sBoOT4VcAdX/CdlDyJy+MMcwjUmZCPYRalt+K
P8Cm26JoxatW2AsRnuxbQkAz2OkjOhzLxemCPwFs2IK70HwZNepzHUsD0XkBBaMj
vEwPjj89Mv1rdqgl7BXqAqYyHFPujvIXeS8fvkUgVjghNlz+PDGWHH9gFYeRL3oo
0AFr0iYlC3qn9uXwRpRtE3GtFgQP+6Epy8C0SZLX/Eipg8sLoOmW3t8IW72OE0FM
dZMwGR3DL3aE7IVwZRINBFkCAwEAAaMeMBwwDwYDVR0TBAgwBgEB/wIBATAJBgNV
HREEAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQCDN/aD1KJnj4TDrXUDAyhihwRlyBmh
uVcXyu2h1+9ZtdeIjnYYbfpT+XegOxtElmH+34W03pMoPj4eKzvLLNGSF6JgFWje
v1nqax15NvvSb1tGbgLd2xkPIkSKy2gRpBnfDj1t0k4jBMq4Tymioqq66YxOybR5
ivoze17Bm3CbCWGu5bM4pbxNeH2sZa5LgcTaY9pr/HkupKIG6o0sOQ4mCvNVaxmw
01in7xj3MzMBriFo0cxiiHfVszADaP7N3eWwxESN15LXQtC9/cFjr6H8FRoaArYh
31UIOWGsjDecaNxohvERYEAnX5LzmPVsA3nnuP2yFMDP/8cRDnZRvOnR
-----END CERTIFICATE-----


스크린샷 2017-07-17 오전 11.41.19.png
94.3 KB View Download
Comment 26 by rsleevi@chromium.org, Jul 17 (4 days ago)
Please open new issues for new bugs. In this case, the certificate is incorrectly set as X.509 v2 (literal 0x1), but has extensions, which are invalid (extensions are only permitted with X.509 v3). In addition, it has a malformed subjectAltName extension (an empty SEQUENCE), but the subjectAltName extension is defined in RFC 5280 as a SEQUENCE SIZE of 1 - meaning there must be one element present.

It is correct that this certificate is rejected.
Sign in to add a comment