I've stumbled upon new technology I want to play with — WebTransport. But there is a problem. It requires very specific certificates. They MUST include ECDSA with the secp256r1 (NIST P-256) named group, and the total length of the validity period MUST NOT exceed two weeks. I wonder if I can issue this kind of certificate via Let's Encrypt?
No, you cannot--Let's Encrypt issues certificates that are valid for 90 days, no more and no less. But that requirement makes me strongly suspect that certificates from a public CA aren't expected, as (to the best of my knowledge) none of them issue such short-lived certs.
7 Likes
I concur, especially looking at the serverCertificateHashes option. Which, if I read it correctly, is used to "pin" the valid server certificate(s). So the public PKI doesn't seem to be used.
4 Likes
GTS should, but I am not sure about client support for this feature.
4 Likes
GTS definitely does allow for certs as short lived as 1 day, though they'd prefer no shorter than 3 days.
Posh-ACME supports variable lifetime certs via the -LifetimeDays parameter. I'm pretty sure other clients do as well in some form or another. But perhaps not certbot?
4 Likes
Right now Let's Encrypt only supports 90 day certificates, but we will likely offer short-lived certificates (7 days or so) in the future. There's no timeline for that launch right now, as it's blocked by several other projects needing to be complete. I don't think it'll happen in the next year.
WebTransport looks like it expects to be passed the hash of a certificate, and doesn't mention anything about validation, so I agree with others saying that I think you're expected to use a simple self-signed cert here, and communicate the hash out-of-band in a regular http API.
I'm not deeply familiar with WebTransport so I can't say for sure, though.
7 Likes
What about a cert that has 14 [or less] days of life left in it?
If that gets it to work, you could forcibly renew your cert(s) every 13 days.
Then only use the one that is good for less than 14 days.
[probably not so easy to automate - but possible none-the-less]
3 Likes
that could be scripted relatively easily. Intriguing idea!
Definitely a "special use case"!
3 Likes
The 14 days limit is for the "total length of the validity period". So nope, your workaround shouldn't work.
1 Like
Yes, clever idea but don't think it is allowed. Highlights mine
the current time MUST be within the validity period of the certificate as defined in Section 4.1.2.5 of
RFC5280and the total length of the validity period MUST NOT exceed two weeks.
Section 4.1.2.5 describes the notBefore and notAfter dates
3 Likes
Yes, "as written".
How is it actually being implemented?
[it wouldn't the first time that someone incorrectly implements an RFC]
Also, is the source code available/modifiable?
If so, it would be simple to change it.
3 Likes
snip
if serverCertificateHashes is specified, instead of using the default certificate verification algorithm, consider the certificate valid .....
entire custom certificate requirements not apply if serverCertificatHashes is NOT set, it will just use default verification, and happily use LE certificate
5 Likes
Good Catch! Thanks for that.
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.