I tried generating a LE cert from a CSR that contained
[…]
Requested Extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication, 1.3.6.1.5.5.8.2.2
[…]
the number is used for “IP Security IKE Intermediate” which is recommended for my use-case where this cert will end up on an ipsec server.
however I end up with a generated certificate that has
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
[…]
so the Extended Key Usage gets completely rewritten. is this the intended behavior?
could the generated certs follow the CSR more closely by using a special API call?
for a bit of context, I am using a modified acme.sh client.
Public CAs typically only allow a small number of EKU flags that are mentioned in the Certification Practice Statement (CPS), in Let’s Encrypt’s case that’s id-kp-serverAuth and id-kp-clientAuth.
CSRs are more or less a wishlist that gets “rewritten” based on what the CA supports (and is allowed to support).
pfg has explained that this won’t work and that it’s intended not to work (thanks pfg)
It might make sense, if ACME popularity continues, to have some CA that issues certificates for IPsec using ACME. In surveying the ecosystem I have found that today the issuance mechanisms used for IPsec (and several other types of x509 certificate issued to devices semi-automatically) don’t do a great job of verifying the applicant’s identity. In a closed environment (e.g. IPsec tunnels between two branches of the same company) identity can be verified out of band by, say, a telephone call between technical staff. But if that’s all you’re doing the use of x509 isn’t really adding anything, it’s just an obstacle. If it’s not too much trouble rodan, despite the fact that Let’s Encrypt can’t really help you here, can you say a bit more about your IPsec setup, and how you came to look for a public CA to trust for identifying your endpoints?
Well, in the case of Let's Encrypt, the CSR's are just a container for some information (CN, SAN, TLS Feature Extension). Using the CSR format is practical, because of its signed nature. But rewritten is, even with quotes around it, hardely the word of choice I would use
I’m evaluating LE for a pretty big infrastructure of public vpn servers. we are currently using an expensive wildcard certificate, but using a wildcard is not only discouraged in ipsec RFCs, unsupported in some client implementations but also bad from a security standpoint.
having per-host certificates would allow the use of nice clients (strongswan). and if LE’s intermediate certs (X3, X4) will end up in the operating systems, this would allow the users to connect without needing to import any CA before connecting to our service.
the “IP Security IKE Intermediate” I’ve been asking about would have been nice for older mac OS X clients, but lacking this feature would not become a show stopper. most OS-es only rely on the “TLS Web Server Authentication” EKU when verifying an ikev2-based ipsec server.
