As far as i know, letsencrypt does not provide certificate for public IPs. I get it that the dns challenge would be impossible, but the web challenge would work (provided you get the right target configuration, of course). The use of ip-based certificate could eliminate the effects of dns-hijacking attacks for sensitive infrastructure (see context bellow).
My quesiton is WHY does letsencrypt not offer certificates for public IPs ?, and please do !
I would just like to understand the reasons, as i cannot see a technical one, because an x509 CN field can be free-form (and should, as per RFC 2818) and SAN records can hold both DNS records and IP addresses.
As for context behind this "need" : we have recently experienced a domain hijacking for some domains, which included the part of our management and security ifrastructure (namely, ipsec remote access gateway). Thus we had to temporary circumvent network things on each of our roadwarrior fleet (namely, changing the remote access settings to use IP addresses, and overriding the trust of the remote gateway for the client to accept to connect to it). So we are thinking of using certificates based on IP instead of domain for our public remote access for management, so we do not depend on DNS. Of course, we could just roll our own PKI and distribute its CA certificates as trusted on the roadwarrior fleet, but these are BYOdevices managed by third parties, which would be quite impractical (but feasible). That was just for context
It was planned, but for some reason (I believe more pressing matters to implement first) it was shelfed. If you search this Community, you might find an explanation from one of the Let's Encrypt staff somewhere. I don't have time currently to search myself, but I believe the desire to implement it is still there. Just not coming soon.
Note that ZeroSSL issues (free) certs for IP addresses, but only using their webinterface (and not their ACME API) and with a max. of 3 in total per account I believe.
I understand the reasons, and i even could see that some work had already been done by orangepizza, which would be taken into acount when the team has tome on its hand for this feature.
I learnt about zerossl (i'm not happy the have access to the private key, but hey). I now know all i need.
Thank you both for the feedback.
Have a good easter hunt.
I would not trust that for the life of me: the encryption key seems to be stored somewhere by ZeroSSL. Try it yourself. Steps to reproduce:
go to zerossl.com and make an account and/or log into your account;
generate, issue and download a certificate;
notice the encryption_key variable in the "Local Storage" for https://app.zerossl.com/ (see the "Application" tab in the Chrome Developer Toolbar e.g.);
delete EVERYTHING in your Local Storage and/or cookies for ZeroSSL.com;
refresh ZeroSSL.com and notice that you're now logged out (makes sense);
login again to ZeroSSL;
notice that you can still download the ZIP file with your certificate and private key;
notice that the encryption_key variable is exactly the same as before.
notice that you still can download the ZIP file containing the private key.
Thus: the encryption key must be stored somewhere on either ZeroSSLs servers or it's some kind of hash from your login and password perhaps.
In any case, I wouldn't trust them.
Edit:
Did some digging in the JavaScript code and the encryption key seems to be the SHA256 hash of your password concatenated twice (i.e. sha256(password + password)). And if you'd change your password, the encryption key would change and it would invalidate the stored encrypted private keys on the ZeroSSL servers.
If you try to change your password, you're shown a warning:
Important Notice
Please download any certificates you have not installed yet
Your certificate files are uniquely connected to your account password, which means that changing your password will cause any certificates currently on your account to become non-downloadable.
Before changing your password, please ensure that all certificates (.zip) on your account are either downloaded or installed on your server. If this is already the case, you can proceed safely.
Ah well, I still wouldn't trust any browser generated private key, too much JavaScript to audit to be sure
Let's Encrypt would like to offer IP certificates at some point but there's compliance and security risks that we'd have to address, and as such it's lower priority than our other work.
There's no CAA records which is a big concern. We'd have to rework a lot of our ratelimiting code which makes assumptions about domains as a scarce entity. We only want to issue short-lived IP certs, which is blocked by a number of other scale challenges in our CA and the CT ecosystem. We don't want to hoist IPs into CNs, so we'd want to enable no-CN certs first. Much of our logging and auditing code will need to be expanded.
None of which is unobtainable, but we are working through those blockers.
