I’m sure that this has to have been answered before but I can’t seem to find it via searching the forums/web. Is there any way to generate a certificate for an appliance or hardware device? For example, HP servers (iLO) and Dell server (DRAC) present a html interface via firmware. Obviously, there is no way to directly run letsencrypt from the device and there doesn’t seem to be any way to generate a certificate for a give hostname, unless I’m missing something obvious. The hardware devices do allow me to install the certificate via a script so I’m really trying to figure out a way to have a remote instance (Linux VM, etc) that can generate the certs/renewals and then I can automate the installation of them. Any suggestions?
As long as you have a domain name (or subdomain) for the specific device, then yes you can.
The easiest is to use the DNS challenge ( not yet in the official client, but a number of the alternate clients support the DNS challenge - the 3 bash clients do ). If you have SSH access to the specific device for uploading certs, then you can use the getssl client (I think the only one that currently automates certs to remote locations - although planned for the official client).
You are my hero! I don’t know how I missed the existence of alternative clients but I was totally oblivious.
Thank you for the quick response!!
Troy
1 Like
Did you manage to get a certificate for ilo4? My problem is that the csr contains the IPv4 and IPv6 address in the SAN section. There is no way (afaik) to avoid this. Is there a method to let letsencrypt ignore the SAN section?
@xyzzy, can you import or export private keys on these devices?
Unfortunately there is no way to extract or import a private key into an HP-iLO4 device 
So I have to live with the CSR as generated by the device. Sample CSR:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: CN=test.test.com, OU=ISS, O=Hewlett-Packard Company, L=Houston$
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
....
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
DNS:test.test.com, IP Address:10.1.100.3, IP Address:FE80:0:0:0$
Signature Algorithm: sha256WithRSAEncryption
....
As you can see HP insists on putting IP-Addresses into the SAN section... I have found no way to avoid this.
That’s too bad! As far as I know, you’re out of luck in this case and should lobby HP, because I don’t believe Boulder will issue a certificate where some of the SANs in the CSR are forbidden subjects by policy. (@jsha, is that right?)
That’s correct. Also note that the domain name (test.test.com) presumably doesn’t actually point to your printer. Since Let’s Encrypt gets the list of domain names for which to issue certificates from the CSR, that would fail.
test.test.com is not the domain I actually want to get signed. Please note that I’m not interested in getting a certificate with the requested IPs in the SAN section. I’d just like to have a method to get the SAN section of a CSR ignored.
@xyzzy, I’m sorry to say that the other problem is still fatal here. There is no way in the protocols that Let’s Encrypt currently uses to ignore SANs. If any SAN is incompatible with LE’s issuance policy, the certificate can’t be issued; the protocol doesn’t have a way to say “I don’t care about these” or “don’t validate these” or “don’t issue for these”.
@schoen just to confirm, there is no way to ask a certificate without a (valid) csr and just with the public key?
That’s correct. A signature from the private key corresponding to the subject public key is required.
1 Like
hi @xyzzy
what environemnt are you using (windows/linux/mix of both)
Active Directory Certificate services are another option I quite often use for these kinds of problems
AD Certificate Services even have a web interface where you can issue certificates
Note: these will only be trusted in your environment however there should be very need to access ILO from outside your network
Andrei
Hi, ahaw021,
I know how to setup a private CA. Its actually quite easy with openssl and we use it for our OpenVPN infrastructure. But using a private CA for https just isn’t practical these days. e.g. you’ll have to live with a permanent warning if you wish to connect from an android device… So even when I don’t need outside access installing a root CA on every device we might wish to use to access iLO is no option. But thank’s for the suggestion.
This is a plugin for the official client that automates cert installation to a remote device (a Cisco ASA). The ASA supports importing certificates and keys, so the plugin just installs the certbot-created material. The ASA doesn't create its own CSR.
A broad suggestion that’s more of a work-around: what if you had one or more reverse proxies for this service, the iLo gets a cert from a private CA, the proxies would grok whatever long-lived private CA is issuing, and then pass through the HTTP connection with a Let’s Encrypt (or whatever else suits) publicly trusted certificate so the proxy interface works from anybody’s laptop or Android device.
These hardware devices are (unless I’m mistaken) providing lights out management, so obviously having just one reverse proxy is a big vulnerability - one bug in that proxy and you’re reduced to driving to the facility to do things by hand, but if the basic principle works, you can replicate the reverse proxy, very scalable.
As a bonus the reverse proxy lets you stop worrying about crappy security in little firmware HTTPS implementations, the proxies are the only things exposed externally and they can be all zipped up tight.
2 Likes
I found a solution for my problem. Including the IP in the SAN is a misfeature of iLO4 2.50. When you downgrade to iLO4 2.44 you will get a csr without IPs in the SAN. So to get a working CSR you downgrade to 2.44, request a CSR, upgrade to 2.50 and use the 2.44 generated CSR to the EOL of the device.
2 Likes
Nice work! And thanks for sharing your solution here.
I was able to verify that HPE is targeting an iLO update in the April timeframe to make the IP address optional in the CSR. Hopefully, the downgrade workaround will only be needed for a few more weeks.