I wanted to share some information for those using Apache. I actually started to post this as a question here, when the solution hit me during my entry of the description of my own problem.
We host our own web server with a couple of different additional domains (SAN)
We already had an SSL with goDaddy. It expires in a few weeks.
Our primary web domain is NOT hosted on our own server however. Just the other SANs.
Our primary web domain points, on our Registrar DNS host records, to an external host. (We have to put it there because we and other branches of the organization all have to “hotel” together under that system).
Installed CTW. Configured it. Ran the test and it would fail with
Well, of course. Because going to our primary domain would then say hey… go to that external server, and CTW cannot access that .well-known folder from this local server.
The fix is to edit the Windows Hosts file and put the web domain in there. It will only affect that server you are doing it on, and it takes precedence over any external DNS records (from our registrar).
127.0.0.1 www.oursite.ca
127.0.0.1 oursite.ca
Now when you run the test, it will succeed, because it will reference the local machine that Apache is running on, and your apache.conf (or vhosts.conf file) will have the correct local pointer to the directory and path for seeing the check files the program needs to access.
Now even though your main web domain is hosted externally, and your other SANs are internal, you can complete the test/verification process.
I uh… have not tried the actual certificate deployment yet. But if the test works… ? I’ll let you know.
I feel like it won’t work. Let’s Encrypt will do something similar and check for a file in that .well-known folder. That’s why the config check is doing that first. It’s the most basic of sanity checks… which is failing.
If you’re requesting a certificate for the primary domain, you must prove you own it. If you can’t prove that you own it, you must remove it from the certificate request. Are you requesting one certificate with all of the SANs grouped together? It does not matter what is the primary domain on the certificate and which are SANs. Just pick one of the local ones to be the primary instead of the domain you cannot control.
Arrrrg. Yes indeed. While the test succeeded , the real request failed. Yes, Lets Encrypt would have then used the web-sourced DNS address for the check of the primary domain of course.
So… are you saying, I just simply remove the primary domain, pick any SAN to be the new primary? This won’t break any of our other sites, mail server validation of the SSL, etc. ? Again, our primary domain is not being hosted on our own server. Sub domains of that are used for mail.oursite.ca and internal.something.ca for example.
Not only will Let’s Encrypt use public records, but it uses various worldwide servers to do the checks to prevent targeted DNS poisoning. You were doing a similar tactic, but the “poison” doesn’t spread past your machine and programs running on it(and it wasn’t technically malicious).
This will only affect the domains being served by your local Apache server that can actually serve the certificate to clients. There are no safeguards on the internet that say you cannot have multiple certificates for the same domain… so creating a certificate does nothing except give you a certificate to serve upon request.
I don’t have a clear picture of your network setup, so it’s hard to answer your questions directly. But the certificate only affects things that serve the certificate. In this case, the Apache server? If your primary domain doesn’t use the certificate, nothing is changed. If your mail server doesn’t use the certificate, nothing changes. It means you have to manage the certificates for those things separately, however. Serving the certificate from Apache doesn’t magically make other programs, like a mail server, also use the certificate.
I have a cloud hosted domain, xxxx.com
I have a local mail, smtp.xxxx.com
I have a local web server, web1.xxxx.com, web2.xxxx.com, web3.xxxx.com.
Certify the Web requests certificates for smtp.xxxx.com and web#.xxxx.com as separate requests. They technically could be a single request with 2-4 SANs… but because the programs serving the certificates are different, I want to restart them separately. web2.xxxx.com and web3.xxxx.com are a single certificate with a random one being primary.
Apache is listening on port 80, so it must serve all local challenge requests… even for smtp.xxxx.com which is not a web server. In Apache, I have HTTP and HTTPS served from different folders to accommodate this, but it is not necessary. All port 80 requests will go to the vhost where Certify is pointed to for all the profiles.
Please note that I have not mentioned xxxx.com, yet. This is because it is a remote server running acme.sh which is a shell-script client for Let’s Encrypt, unrelated to Certify.
Yeah so you can defeat our config checks by tricking the app into thinking the request will work (with a hosts file or local dns etc) but the real request will only work if you validate your domain control.
Luckily though, there is more than one option:
If you don’t need your primary domain on that servers certificate, then you don’t need to include it in the cert (as you say it’s a different server that’s handling that exact domain, so that domain isn’t used on that server). Http validation checks that your server responds with a specific challenge response at the given domains, so if all the domain you mention are hosted on the server Certify is on then you can do that. Let’s Encrypt doesn’t have specific restrictions on which domains are on which certs and you can double up/mix and match domains in different certs.
If you do still want your primary domain there just for completeness but can’t use http validation, you can use DNS validation instead. DNS validation uses a TXT record in your public DNS instead so that it doesn’t matter who/what hosts your domain as long as you can set the TXT record as required. You would ideally host your domain(s) with providers which have a supported API, our you can provide scripting, or you can use acme-dns (CNAME redirection to a challenge response service).
Manual DNS validation by setting the TXT record via your dns control panel is also possible but I strongly recommend against manual processes unless you’re just testing.
Thank you folks, much appreciated for your excellent insight and help.
I will make the tweak tonight and give it a try then for removing the primary domain. That way if I have buggered something up and it suddenly causes certificate warnings, I at least have overnight to fix things
Can you clarify one thing about the non-professional version limits? I believe it says up to 5 separate certificates for the community-minded running of the software. In our case we have just one. But is there also a limit to the number of supported SANs in a single certificate for the community version?
Edit Note: the Registrar we use does not support any API for DNS verification processes (Register.ca) I wish I could have used this approach as I think it would be far better.
Hi, no there is a Let’s Encrypt limit of 100 SANs per certificate, so technically you could cover 500 domains across 5 certificates. The apps doesn’t limit SANs other than enforcing the Let’s Encrypt limit.
Still having a problem here.
I removed what is our primary domain and only list the sub-domains.
Thus the Authorization Tab is now using the match domain approach:
a) A domain match for mail.olddomainformat.on.ca, mail.domain.ca;my.domain.ca which all point to a common Site Root Directory folder
b) an entry for anotherdomain.ca which points a different Site Root Directory than (a)
c) an entry for onemoredomain.ca which points to a different Site Root Directory than (a) or (b)
When I look at the logs, every domain succeeds except mail.olddomainformat.on.ca
When I look at the folder as the process runs, I can see it create a file in the Challenge folder, and then that file disappears. In the log, that same file is the one it shows as being “connection refused” for the mail.olddomainformat.on.ca
Why is it deleting that challenge file for that domain before the test has been able to use it to complete the verification process?
Hi, connection refused is different to not found and generally means that whatever that domain is pointing to doesn’t allow port 80 http traffic (a firewall or there is nothing listening). Check your old (and new) domains with https://letsdebug.net to ensure they are all being served by the same IP. With the http challenge validation all the domains need to be point to the same server that Certify is running on (or at least where your challenge response files are being written to). The cleanup happens after the check fails.
That tool is great to have, thank you. It provided much clearly steps of what was going on.
It is trying to actually reach a site of mail.olddomainformat.on.ca - but that doesn’t exist of course. We wouldn’t have a web page for the mail function, just the mail server software itself. So even though I told it to use the Site Root Directory of the main website, it will look for a page at “mail.?” I have to setup a website for mail?
Yes, if you weren’t using Apache then Certify could pretend to be the website just for the purpose of http validation, but Apache unfortunately doesn’t know about http.sys and the windows kernel http pipeline (it just has it’s own), so you can’t benefit from that and instead you will have to present a website for that domain (even an empty one) just for the purpose of completing http validation.
I wish I could have used this approach as I think it would be far better.