New issue
Advanced search Search tips

Issue 715969 link

Starred by 6 users

Issue metadata

Status: Duplicate
Merged: issue 717905
Closed: May 2017
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug

Sign in to add a comment

ERR_SSL_SERVER_CERT_BAD_FORMAT without explanation

Reported by, Apr 27 2017

Issue description

Chrome Version       : 59.0.3071.25 dev
OS Version: OS X 10.12.4
URLs (if applicable) :

What steps will reproduce the problem?
1. navigate to

What is the expected result?
redirect to

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

Please provide any additional information below. Attach a screenshot if

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.
102 KB View Download
91.1 KB View Download

Comment 1 by, Apr 27 2017

Components: Internals>Network>Certificate

Comment 2 by, Apr 27 2017

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,  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.)

Comment 3 by, Apr 27 2017

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?)
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.

Comment 6 by, Apr 27 2017

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 (was: Unconfirmed)

Comment 14 by, May 4 2017

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.

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:

Apparently they had a bug in their workflow, see

The last buggy cert was issued April 2016.
Project Member

Comment 16 by, May 5 2017

The following revision refers to this bug:

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

X509NameAttribute::ValueAsString: Decode TeletexString as Latin1.

BUG= 717905 , 715969 

Cr-Commit-Position: refs/heads/master@{#469812}


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, May 8 2017

Labels: merge-merged-3071
The following revision refers to this bug:

commit 8a4fb425dc1e081b5942975f0d1c852aae2819e6
Author: Matt Mueller <>
Date: Mon May 08 20:20:42 2017

X509NameAttribute::ValueAsString: Decode TeletexString as Latin1.

BUG= 717905 , 715969 

Cr-Commit-Position: refs/heads/master@{#469812}
(cherry picked from commit 788812f7788c07aa58487523ec70f9e921d78543)

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


Hello, I have similar issue since Chrome 59.something

trying to access

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 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):

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.
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?


스크린샷 2017-07-17 오전 11.41.19.png
94.3 KB View Download
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