I’m trying to get a LE certificate for a machine on a LAN running Ubuntu. The machine only has a private IP address and the Microsoft ISA server redirects all traffic to its IP:8080 to that box. The network has other machines set up with existing SSL certificates including mail and domain controllers. The setup is similar where those boxes are configure on non-80 port and when traffic hits the firewall it gets redirected to the specific box.
Now I’ve tried to set up LE on port 8080 by using commands I found only rather than the simple line letsencrypt --apache -d sub.domain.com and either way I always get this error message:
Failed authorization procedure. sub.domain.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 04b2a6514ea07cdb36d6fac73645bb04.70e21dacb2f3610150d93cdf2f14ad76.acme.invalid from IP:443. Received 2 certificate(s), first certificate had names “autodiscover.domain.com, dpcedgesvr.domain.com, dpcmailsvr.domain.com, mail.domain.com”
The following errors were reported by the server:
Detail: Incorrect validation certificate for tls-sni-01 challenge.
2f14ad76.acme.invalid from IP:443. Received 2
certificate(s), first certificate had names
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.
Any idea what I should do next?
By default, the
--apache option uses tls-sni-01 to verify you own your domain. Basically, certbot configures apache to serve a special certificate and then asks Let’s Encrypt if it can see it.
When you proxy the connection to your server at the HTTP(S) level, there’s no way Let’s Encrypt can see this special certificate, so you cannot verify your domain in this way.
Also, this means the certificate Let’s Encrypt would install will not be seen on the public Internet. The certificates as used publicly are served by your firewall, so you must install certificates there if you want them to be used for that purpose. (There are several Let’s Encrypt clients for Windows.)
Or do you just intend to use your Let’s Encrypt certificate to secure the connection between your firewall and your origin Ubuntu server? (Or maybe you wanted to copy it to the firewall after issuing it?)
Ohhh… right! Thank you for those explanation. I’ll try to install the certificate on the Windows machine then and see how it goes.
If you do happen to have an API that allows you to update DNS records in your DNS zone, there is also a way to prove your control over the domain name that way, which is often a good way to get certificates for machines that are behind firewalls and that have a restricted ability to receive incoming connections.
Still struggling with this. As a side note I am not the one handling the MS ISA Firewall so my testing abilities are limited. I am being told that adding a SSL certificate to the ISA Firewall is password protected. Not sure how to configure that on the clients. Is there any documentation on setting up LE with this MS ISA Firewall product?
Ok seems that’s a tricky one. So now I’m having another related issue of using a firewall and having the certificate on the firewall: how do I configure the apache2 website configuration file with the certificate not being on that server and in a different format (crt vs pfx)?
For the first part, you could try using DNS verification. If you are using a DNS provider that has an API, you can even automate the process. Alternately, you could use something like Certify or letsencrypt-win-simple directly on the server.
As for the certificate format change, that’s pretty straightforward. The format certbot and most *nix tools use is called PEM. Windows uses PKCS12 (pfx). You can use the openssl tool to convert the formats with a command like:
openssl pkcs12 -export -out certificate.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem
OK. First, thank you for the prompt reply. Second I have a few questions:
- DNS synchronisation is super slow from the current provider, so when trying this method manually it times out before the DNS has propagated. I suppose (maybe wrongly?) that the same will happen if there is an API access. It uses Cpanel and Cpanel does seem to have an API
- You actually mean I still need to have the PEM certificate on the Linux box? So in short I manage to generate the PKCS12 certificates on Windows (not sure how to automatically enter them into ISA DB yet but hey…1 step at a time), copy them on Linux and convert them? Meaning I always need the certificates on each box at all time?
- Well I still need to figure out how to enter the PKCS12 certificates into the MS ISA interface.
Thank you for your help.
I guess we were confused as to whether you were running a Let’s Encrypt client on the Windows server now or not. They can actually run openssl there if they need to but shouldn’t have to because most Let’s Encrypt clients take care of the pfx conversion for you.
Usually there is no pfx password, and you just hit Enter or Continue and go on, and this works with IIS, but some other programs require that you type something in the field to go on. For that reason most Windows Let’s Encrypt clients have a option to set the password to whatever you want. (e.g. the
PfxPassword option in letsencrypt-win-simple’s config file)
Remember, Apache only ever communicates with the ISA firewall. If the communication between Apache and the ISA firewall occurs over a private network, and you’re not worried about three letter agencies tapping it like they did Google’s, you could continue to use HTTP for that.
If you do want to secure the connection between the ISA firewall and your Apache origin server, you could indeed use the same certificate if you wanted, but passing around private keys isn’t ideal. You could also run certbot independently on your Linux server, but this may not work anymore if your ISP rerouted the required path to their servers so they could get you a certificate.
Ideally, they would use Active Directory Certificate Services to issue you a long-lived certificate trusted by the ISA firewall, so you don’t have to mess with that side very often.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.