Does Let’s encrypt support custom certificate extensions inside a certificate? I would like to add some custom payload to it and get it signed together with my certificate.
Let’s Encrypt adds certain whitelisted extensions to the end-entity certificates if they’re included in the CSR (for example the OCSP Must-Staple TLS extension - I can’t think of any others right now, so it might be just that one), but not any custom extension. It would be bad for a CA to sign certificates with extensions it does not understand, so this is usually done with a whitelist approach where certain (whitelisted and safe) extensions (and other data) are extracted from the CSR rather than taking the CSR as the template for the final certificate.
Is there any list of accepted field names by Let’s encrypt? We would like to add some extra information as a research project to allow better verification on the client and protection against server compromises. So we are search for a field where we could put an extra signature payload.
No, you won’t be able to do this. For a research project I would suggest you start from a CA under your control. During experiments you can set test systems to trust this CA, and if you find anything useful you can present your results either to the CA/B Forum, or to trust store owners like Mozilla directly. If you have a compelling new verification method it is possible that CA/B will permit CAs to sign this extra data once it has been shown working.
1 Like
Hm, you are probably right that this would be the best official way, but I still wonder if there is any field I could hijack for this purpose. 
I read around that people are misusing otherName for this purpose. Does Let’s encrypt support this field?
The SAN otherName field can’t used with Let’s Encrypt. Let’s Encrypt offers only dNSName SANs.
I’m still wondering why you would use an extension as extra verification against “server compromise” in a research setting…? What’s the idea behind it?
The idea is that we can then claim backwards compatibility. So users can use then see server as normal HTTPS server certificate signed by a CA, or if they have our browser extension, they can better verification. We can then run a public experiment and users do not have to install anything extra (because certificate would be signed by a trusted CA), or they do (a browser extension) and they then can get extra layer of verification. If we have to say “our idea is nice, but it will require a standard body to adopt it”, it feels much less neat. So it would be great if we could have a field to use in meantime, and then later on it can be standardized and decided upon which one to have dedicated, if our approach proves good.
I understand exactly what the OP is out after: Some field, indtended for any data, but that is not verified by the CA. Eg, some opaque field, which according to standard, should NOT be verified by the CA, and should NOT be trusted by the client. Some “comment” field or whatever.
How large is the payload? It might be possible to steno-encode that payload into the public key of the certificate (by carefully “bruteforcing” the public key into a public key with certain bits set) (think like Vanitygen to Bitcoin).
But that can only store a few bits, I think up to about 8-16 bits (bits!, not bytes!) maximum before it become infeasible to bruteforce a known sequence into the public key. But it can be excellent to store certain boolean settings into the public key, that your browser extension can “read”.
There is a field in the CSR called Challenge, that is not verifyed by the CA, but included in the cert verbatim what I know of, I don’t know if Let’s encrypt support that.
1 Like
For what it’s worth, Firefox is the only browser that gives extensions enough power to implement the type of extension you are proposing, and they are likely to restrict that power in the future.
I would not recommend trying to twiddle bits into the keypair, since there’s a good chance of decreasing the key strength by accident.
As others have said previously, Let’s Encrypt intentionally won’t sign extensions it doesn’t understand.
The CSR's challenge password is not included in the certificate. It's a crude mechanism by which a CA can perform an out-of-band verification of identity. As such it's also not relevant to systems like Let's Encrypt.
Yes, I know that Firefox is the only one at the moment. And even that might go away. This is really sad. Because extensions like Certificate Patrol will then stop working altogether. This SSL collection of Firefox extensions is a great list of various things you can do if you can access SSL verification.
Sadly, few bits will not be enough. We want to include SGX attestation into the key. And it would be great if legacy users could just trust SSL, but users with an extension could also verify that they are really talking to a particular code.
Current crazy idea is to store that into a subdomain. So we do <data>.example.com as the domain. (In our particular case domain will not be exposed to the user.)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.