On the duration of self-signed TLS (website) certificates

April 18, 2024

We recently got some hardware that has a networked management interface, which in today's world means it has a web server and further, this web server does HTTPS. Naturally, it has a self-signed TLS certificate (one it apparently generated on startup). For reasons beyond the scope of this entry we decided that we wanted to monitor this web server interface to make sure it was answering. This got me curious about how long the duration of its self-signed TLS certificate was, which turns out to be one year. I find myself not sure how I feel about this.

On the one hand, it is a little bit inconvenient for us that the expiry time isn't much longer. Our standard monitoring collects the TLS certificate expiry times of TLS certificates we encounter and we generate alerts for impending TLS certificate expiry, so if we don't do something special for this hardware, in a year or so we'll be robotically alerting that these self signed TLS certificates are about to 'expire'.

On the other hand, browsers don't actually care about the nominal expiry date of self-signed certificates; either your browser trusts them (because you told it to) or it doesn't, and the TLS certificate 'expiring' won't change this (or at most will make your browser ask you again if you want to trust the TLS certificate). We have server IPMIs with self-signed HTTPS TLS certificates that expired in 2020, and I've never noticed when I talked to them. Also, it's possible that (some) modern browsers will be upset with long-duration self-signed TLS certificates in the same way that they limit the duration of regular website TLS certificates. I haven't actually generated a long duration self-signed TLS certificate to test.

(It's possible that we'll want to talk to a HTTP API on these management interfaces with non-browser tools. However, since expired TLS certificates are probably very common on this sort of management interface, I suspect that the relevant tools also don't care that a self-signed TLS certificate is expired.)

I'm probably not going to do anything to the actual devices, although I suspect I could prepare and upload a long duration self-signed certificate if I wanted to. I will hopefully remember to fix our alerts to exclude these TLS certificates before this time next year.

PS: The other problem with long duration self-signed TLS certificates is that even if browsers accept them today, maybe they won't be so happy with them in a year or three. The landscape of what browsers will accept is steadily changing, although perhaps someday it will reach a steady state.


Comments on this page:

From 193.219.181.219 at 2024-04-19 04:18:05:

PS: The other problem with long duration self-signed TLS certificates is that even if browsers accept them today, maybe they won't be so happy with them in a year or three. The landscape of what browsers will accept is steadily changing, although perhaps someday it will reach a steady state.

So far, the main "explanation" has been that with public CAs, it's the validation results that have a short lifetime. Since this doesn't apply to private CAs (where the issuer itself can usually prevent things like domain/username reuse), I'd assume browsers will continue to accept long-lived certificates as long as they're issued by private CAs.

Having something internally like XCA or step-ca or Easy-RSA can make management connections a little less annoying when you can issue a 50-year certificate...

By Olin Mcclain at 2024-04-19 12:01:02:

even if browsers accept them today, maybe they won't be so happy with them in a year or three

One can't really win with assumptions like this. We could just as well suppose that browsers will stop accepting expired certificates, even self-signed ones. And to me, that would make more sense: the certificate issuer wouldn't have set an expiry date if they didn't want it to expire, right? (RFC 5280: "To indicate that a certificate has no well-defined expiration date, the notAfter SHOULD be assigned the GeneralizedTime value of 99991231235959Z." I assume that value can be given via -enddate to openssl-ca. I also assume some implementations will overlook the special meaning of this timestamp: late in the year 9999, some CA's gonna accidentally issue an infinite certificate—of course revocation will still be an unsolved problem at that time—and then, in 10000, some clients will accidentally reject intentionally-infinite certs.)

A 50-year certificate, as suggested by 193.219.181.219, seems like trouble. Because there's almost certainly no good basis for that timeline (why will the key remain secure for 50 years but not 60?), and there's a chance the certificate will still be around—with less chance anyone will remember issuing it. I made the mistake once of using a 3650-day expiry on a certificate for logging into IRC; that's what the example I copied used. A decade later, NickServ started giving me warnings out of nowhere, and the term "expired" was never mentioned and it took a while to figure out.

Written on 18 April 2024.
« Limiting the maximum size of Amanda debug logs with a Linux tmpfs mount
Modern Linux mounts a lot of different types of virtual filesystems »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Thu Apr 18 23:15:36 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.