TLS certificates specifying hosts via the CommonName field is more or less gone
utcc.utoronto.ca
utcc.utoronto.ca
What actually resulted in this finally happening was not the change in the browsers, in fact the browser changes were permitted by the reality that there aren't certificates without SANs any more. Though I agree the browser change does prevent backsliding. Nor was it the change in the Baseline Requirements which spell out that CAs must use SANs.
No, what mattered was Certificate Transparency. Especially mandatory CT, but even just voluntary compliance by CAs eager to show willing before that.
The problem we've most consistently had with CAs isn't that they're deliberately breaking the rules, but that they're incompetent. Which makes sense, humans aren't mostly bad but they are mostly incompetent. So they might intend to comply, but they screw up.
CT allows independent researchers to check stuff. For example after certificates for "private names" (e.g. "hplaserjet" or "myrouter.home") were banned, there was a period when CAs mustn't issue more but had time to revoke any that still existed. After that time limit expired I ran a script to pull out any certificates from CT which (in the script's opinion) seemed to be for private names, yet (again in its opinion) had not been revoked. There shouldn't have been any. But of course there were and the CAs had to clean up their mess.
This allowed us to really clean up several problems with certificates, where a practice was banned, everybody agreed it was banned, but it kept happening anyway. Today if you issue a certificate that shouldn't exist (as we saw recently with that 1024-bit RSA certificate) it's likely to get noticed fairly quickly and you'll have to explain yourself.
Came here to say this. Many old printers from HP don't work anymore not due to planned obelescence (which is another problem) but due to sheer incompetence.
Their web interface allows setting "important" details only via SSL even though their firmware doesn't even have a password or login access feature. The web app will redirect constantly using location headers if you try to use some settings views in the web app via http.
Nowadays you cannot use those printers anymore because all Browsers mark them as an insecure context, and therefore are blocking POST XHR requests to manually allowed and installed certificates.
So, we now have a generation of tech that made itself useless due to Browser behavior changes and there's no way to fix it without going back to a Windows XP-state operating system that is insecure.
I am so annoyed by this. We need open source printing firmwares, because I think it's only gonna get worse in future.
I'm not sure if you're aware, but Stallman being denied the source code for a new Xerox printer led to him founding GNU and the FSF.
But it's also possible you're thinking of TÜRKTRUST, which mistakenly issued Intermediate CA certificates to subscribers asking for leaf certificates, resulting in creation of a google.com certificate issued from one of these bogus intermediates. TurkTrust is no longer trusted by Mozilla but I believe it is still trusted in Windows just locked by the "notBefore" policy to restrict the date range of certificates covered.
Or NICCA in India, which I believe was only ever trusted by Windows, and had some problems the full details of which aren't public but included attacks on Google.
Or possibly CNNIC, which we know effectively authorised a third party to mint fraudulent certificates as part of some sort of misguided "security" feature and so was distrusted.
But probably it's DigiNotar you were thinking of, that's the closest match to your description although "to government" sort of implies this was specifically done on instruction of the Iranian government and I don't think that was ever proven.
Alas last time I paid attention Python's code was pretty bad. They got themselves into a mess by trying to think about the DNS name as text, and thus Unicode, and so they persuaded themselves they care about Ulabels, which are intended as a presentation system (ie they're about what we show in a user interface so that a random Cambodian peasant and a Russian oligarch both get squiggles that they recognise even though DNS was invented by Americans) rather than only the Alabels (a restricted subset of ASCII used by the DNS backend). So whereas the correct way to check if this site's certificate is for the right name is to compare the bytes that make up the DNS name to the bytes in the SAN dnsName of the certificate, which is trivial, they ended up needing to do a bunch of Unicode conversion work, pulling in libraries of other code, which was obsolete and... it becomes a huge mess.
The end result is Python worked fine for some.name.example but might break for say кц.рф (the Registry for public Russian TLD рф) because, even though it doesn't matter at all, they're trying to turn it into a Unicode string.
Maybe somebody who focuses on this can say if this was fixed? I stopped caring in 2018 after I had explained all this twice to relevant people. Banging your head against a wall is bad for you and the wall doesn't care.
> Having a Subject Name in general is common (although apparently not actually required)
It depends on what you mean by "required". A name (which a subjectName is) is a list of sets of key/value attributes; that list will always be present, but it might not have anything in it. (It might be the empty list.) (Whether you count a present, but empty, list as fulfilling the word "required", I leave up to you.)
> See also, which pointed me to no-subject.labs.vu.nl, which has a currently valid TLS certificate with no Subject Name at all.
It's there, and it's empty.
The structure is: (read "SEQUENCE" here like "struct"; a list is closer to a "SEQUENCE OF")
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
117:d=2 hl=2 l= 30 cons: SEQUENCE # validity
119:d=3 hl=2 l= 13 prim: UTCTIME :201017024909Z # start
134:d=3 hl=2 l= 13 prim: UTCTIME :210415215900Z # end
149:d=2 hl=2 l= 0 cons: SEQUENCE # subject
151:d=2 hl=4 l= 290 cons: SEQUENCE # subjectPublicKeyInfo
I believe there's also some requirements on it being non-empty. The article's author is looking at it mostly from the point of view of leaf certs, and there, it can be empty. On CA certs, however, it can't be empty. (Because "Issuer" can't be empty on certs issued by the CA, and it must match the Subject of the CA cert, ergo, Subject must be non-empty there. Doesn't have to have a CN, though.)
(All of this is in https://tools.ietf.org/html/rfc5280)
(But, yeah, like the article says, using CN for checking the domain is dead.)
req_nocn() {
local key=$1; shift
key "$key"
stderr_onerror \
openssl req -new -"${OPENSSL_SIGALG}" -subj / -key "${key}.pem" \
-config <(printf "[req]\n%s\n[dn]\nCN_default =\n" \
"distinguished_name = dn")
}XML came out a year after SSL 2.0, so the timing wouldn’t have worked for it.
Assuming that's in the neighborhood of a 20 byte savings, it's not very significant. Using EC keys rather than RSA keys if possible is a bigger savings. And disabling TCP Timestamps, which add 12 bytes per packet (including ACKs) would be bigger still[1].
That said, shaving off bytes wherever possible adds up.
[1] I've heard that disabling TCP Timestamps may disable receive window scaling on iOS (and maybe macos), see [2] for a report. It's also very useful to avoid problems with wrapped sequence numbers if your (bytes/time * assumed maximum segment lifetime) is anywhere near 32-bits; this usually requires around a gigabit on a single TCP connection. As the link mentions, tcp timestamps do make retransmits have different content than the original send, which can incidentally help if you have broken networking equipment on your path, depending on the details of the brokenness.
[2] https://www.snellman.net/blog/archive/2017-07-20-s3-mystery/
I'd actually like to see more servers doing this. In TLS 1.3 it's actually free (in earlier versions signalling the intention to pad costs some space so it's possible you've got some free space but not enough to add padding without using a whole extra packet), but in TLS 1.3 as a side effect of other changes needed you can add any number of empty padding bytes to a record). This means an adversary loses some precision in estimates of your payload size from size of TLS transfer, which may reduce their ability to fingerprint these payloads.
> That said, shaving off bytes wherever possible adds up.
If this matters (and I'm not convinced it does when you aren't shaving off whole packets or making space for something else) other tricks you can do:
* Arrange to obtain unlogged certificates from your issuer. To be trusted by browsers and perhaps in future other clients, your certificates must have proof they were logged in the Certificate Transparency system, most issuers will sort this out for you, log certificates and bake the resulting proofs inside your certificate. But this makes the certificate bigger, you can legitimately obtain certificates which aren't logged, log them yourself, and hand over the resulting proof only to clients that insist on seeing it, thus saving bytes
* Implement the certificate compression feature RFC 8879. Many clients today don't do this, but more will over time, this TLS 1.3 feature lets you compress the certificate before sending it to a client that understands how to decompress it.
* Use smaller keys (2048-bit RSA but more importantly if possible a smaller elliptic curve key)
* Get short names for things, only use those names. A certificate for some.short.example and longer-name.our-company-is-famous.example is worse, because that has both names in it, but if you can get OK to just use some.short.example that's saving a few bytes even if you only have SANs and no Common Name at all.
* Get issuer to disable unnecessary verbiage. Many certificates are full of disclaimer text and needless baggage. Does your issuer realise those cost you money? Does this site need to say YCombinator is in San Francisco which is in California? Does anybody who cares check the certificate? This sort of thinking is why Let's Encrypt's replacement for "Let's Encrypt X3" is just named "R3". We know which CA made it, so why waste bytes saying so twice?
> I'd actually like to see more servers doing this. In TLS 1.3 it's actually free (in earlier versions signalling the intention to pad costs some space so it's possible you've got some free space but not enough to add padding without using a whole extra packet), but in TLS 1.3 as a side effect of other changes needed you can add any number of empty padding bytes to a record). This means an adversary loses some precision in estimates of your payload size from size of TLS transfer, which may reduce their ability to fingerprint these payloads.
Yeah, I think this is a good use of not entirely needed bytes. Even though it's way more bytes than repeating one of the hostnames. Of course, it puts more emphasis on path MTU working, especially if the client does it too. It seems very likely the server side of the handshake will easily fill at least one whole packet, unless you've got jumbo packets or terrible packetization.
You may be able to choose (so long as you obey this constraint) by setting your desired CN in the Certificate Signing Request.
If you meant how should you pick? Well that's up to you. From a presentation point of view, the CN may be used to display the certificate's subject in some summary views so you might want a short but sufficient name to describe what it's for, if it also includes aliases that are more confusing or less specific.
From a compatibility point of view, older software might (erroneously as this article points out, PKIX introduced SANs over twenty years ago, time to upgrade) only check CN and so you might want to reserve the CN to be for a name used by the oldest crumbliest clients. If you've got archaic.mycorp.example and modern.mycorp.example and experimental.mycorp.example with archaic still offering TLS 1.0 and 3DES to that valuable yet tragically slow to upgrade customer who insists on it, well I'd put archaic.mycorp.example in the CN field because if there's a client that'll expect it there it'd be the one that's still needing TLS 1.0 or 3DES not the one built last week.
Another compatibility idea, don't put the obvious name in the CN for the test servers, use some other name you own that's harmless - this way people integrating your system will run into the "It doesn't work because our crappy library doesn't do SANs" problem during early testing not when it goes to production or some day when your production certificates change the value of CN.