I ran this command: sudo certbot --apache -d www.tezzius.ie
It produced this output:
The following errors were reported by the server:
Domain: www.tezzius.ie
Type: unauthorized
Detail: Incorrect validation certificate for tls-sni-01 challenge.
Requested
04529f2ad66ed5b702377d7e845b9157.fdc78dc50c22902407ae3df70ddd96d8.acme.invalid
from 93.107.39.104:443. Received 1 certificate(s), first
certificate had names “”
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
My web server is (include version):Apache/2.4.18 (Ubuntu)
The operating system my web server runs on is (include version): (ESXi 6.5 host) Linux Mint 18.1 Serena (GNU/Linux 4.4.0-53-generic x86_64) (VM)
My hosting provider, if applicable, is: Selfhosted
I can login to a root shell on my machine (yes or no, or I don’t know): Yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No
This seems to be a common issue, but none of the other solutions worked at all.
As above, I recently had my nameserver configuration done correctly on the domain provider side, so it all works. I set up the DNS server on my network myself, so it’s probably a configuration issue there, I’m much more of a hardware person, so I’m not the best at software like this. I tried to obtain an SSL cert, and was met with that error. I previously tried to get a cert, so it might be to do that possibly, but I thought I’d ask first. I also tried just tezzius.ie but it had the same issue. I used the command apachectl -V to get the apache version, but I noted it had this on the first line of the output, “AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1. Set the ‘ServerName’ directive globally to suppress this message” so I suspect it’s the DNS on my side. If you need anymore information I can provide it.
It does seem to be a common issue. Sometimes it happens because people don’t realize they need to run certbot on the same machine as Apache, or because they have a reverse proxy in front of it, but I suspect neither of those is the case here…
More likely, certbot is trying to configure a temporary VirtualHost in Apache with a special certificate to respond to the domain validation challenge, but one of your existing virtual hosts is taking precedence and serving a self-signed certificate instead.
Can you please post the output of the following command:
Yes, VMWare ESXi is domain aware, the host itself talked to my router, which also has DNS stuff (my network is not ideal for this, there is some conflict that I’m trying to work out) and got the name localhost.localdomain, so idk if those settings would interfere, or it something like you said was going on.
The output from sudo apachectl -S is
AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1. Set the ‘ServerName’ directive globally to suppress this message
VirtualHost configuration:
*:80 127.0.0.1 (/etc/apache2/sites-enabled/000-default.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: “/var/www/html"
Main ErrorLog: “/var/log/apache2/error.log"
Mutex watchdog-callback: using_defaults
Mutex default: dir=”/var/lock/apache2” mechanism=fcntl
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name=“www-data” id=33
Group: name=“www-data” id=33
Ah, I missed that it was a virtual machine. Is the host or something else listening on port 443? There’s a self-signed certificate coming from somewhere, you’ll see it if you connect to https://www.tezzius.ie - can you figure out where that is?
When you use certbot --apache you need to run it on the same machine Apache - and more specifically, the Apache instance that you want to use to serve HTTPS. In the case of virtual machines that means either both on the host or both on the same guest. If you want Apache serving HTTPS inside the VM, you’ll need to make sure the host forwards port 443 to the VM.
(sorry I can’t be more specific but I haven’t used VMWare myself…)
Yes it’s all on the one guest OS, due to my awful (actually good by ISP provided router standards, had a version of openWRT on it) router and not working with port forwarding, the VM is in the DMZ, the host is not, VMWare ESXi is very network transparant, so it works well. I don’t think the host’s cert can be accessed from the outside, but I’ll see if I can find it, although deleting it isn’t a good idea. I’ll see if I can find out more info regarding ESXi.
It’s not that the host’s cert needs to be deleted - rather, that if something on the host is listening on port 443, it needs to stop, and forward that port to the guest instead. Something is listening on port 443, and based on the output of apachectl -S, it doesn’t seem to be the guest.
http://canyouseeme.org shows that port 443 is open, so whatever is listening to it, is definitely on the guest OS, it’s the only machine that can, since it’s in the DMZ, it’s the only machine that can accept outside traffic.
I tried uninstall and reinstalling most of the certbot stuff, but it still returns the error, I’ll try turning off the VM and seeing if the port is open still, and maybe dedicate a whole NIC to the VM (it’s running on a HP ProLiant DL380 G7 so there are 3 spare ones)
Interesting. Perhaps you could share some more of the Apache configuration? Perhaps the self-signed cert is somehow being served from there. Maybe try this:
grep -Ri sslcertificate /etc/apache2
(If anything other than Apache was listening on the guest OS, you should have received a different error message about the address being already in use)
Yeah, while off, there is no route to host from canyouseeme, so I think it’s something very local to that guest OS.
The result from grep -Ri sslcertificate /etc/apache2 is
/etc/apache2/sites-available/default-ssl.conf: # SSLCertificateFile d
irective is needed.
/etc/apache2/sites-available/default-ssl.conf: SSLCertificateFile /
etc/ssl/certs/ssl-cert-snakeoil.pem
/etc/apache2/sites-available/default-ssl.conf: SSLCertificateKeyFile /e
tc/ssl/private/ssl-cert-snakeoil.key
/etc/apache2/sites-available/default-ssl.conf: # Point SSLCertificat
ChainFile at a file containing the
/etc/apache2/sites-available/default-ssl.conf: # the referenced file
can be the same as SSLCertificateFile
/etc/apache2/sites-available/default-ssl.conf: #SSLCertificateChainFile
/etc/apache2/ssl.crt/server-ca.crt
Hmm. But that shouldn’t have any effect if there isn’t a symlink in sites-enabled…
Can you find out what’s actually listening on port 443 on the guest?
sudo lsof -i :443 | grep LISTEN
Also, might be worth having a look at that snakeoil cert; if it’s the one being served you might then be able to find something by searching for its name.
Subject: C=IE, ST=Leinster, L=Dublin, O=FUN
IE is Ireland, Leinster is the provenance and Dublin is the county, which would be where I am, so it has the location correct, the result of openssl x509 -text -noout -in /etc/ssl/certs/ssl-cert-snakeoil.pem is
So it looks like nginx is listening on port 443. Do you know about that? Is it intentional?
If for example you're using nginx as a proxy to forward traffic to an Apache backend, then you should be using certbot --nginx rather than certbot --apache.
Me too
Well that confirms this is not the certificate we're looking for (since it doesn't match "C=IE, ST=Leinster, L=Dublin, O=FUN"). But at this point I think we can guess it will be found in the nginx configuration anyway.
You shouldn't post private keys of course, but that's a public key, which is fine
Oh, OH, my friend has Rocketchat set up on this server with a reverse proxy to port 80 for encryption, could that be causing the error that we’re getting? And cool, I don’t see many people from Dublin, only a few each year (currently on number 3 now)
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for www.tezzius.ie
Cleaning up challenges
Cannot find a VirtualHost matching domain www.tezzius.ie. In order for Certbot to correctly perform the challenge please add a corresponding server_name directive to your nginx configuration: https://nginx.org/en/docs/http/server_names.html
It’s possible, although I would have expected a different error message… Apache should fail to listen on port 443 when nginx is already listening there. Still, it may be worth a try… you would need to set up a virtual host (server block) in nginx with a server_name for www.tezzius.ie and configure it to forward traffic to your Apache instance. Then you should be able to get the cert with certbot --nginx.
Sorry though, I can’t be much more help than that… if it were apache proxying to nginx, I could tell you exactly what to do, but nginx configuration isn’t my forte.
Right, I found the issue, after asking my friend “yo what exactly did you do?” he put a nginx self signed cert on it, that would be the cert we where seeing, so all I gotta do is go and remove that.
The thing is: whatever is listening on port 443, that is what needs to be configured with a valid certificate. So if nginx is listening, then nginx needs a valid certificate.
If you want to use Apache to handle HTTPS connections on port 443, you’ll have to stop nginx from doing so. That would probably interfere with (ie. break) rocketchat, so I’m guessing you don’t want to do that.
However you can set up nginx (or apache for that matter) to run with two different certificates, one for your domain and one for whatever domain name your friend is using. Just set up a server block for each, and in theory certbot --nginx should do the rest… The traffic on port 443 will be handled by nginx though, so if you want to use apache you’ll have to configure nginx to proxy the traffic for your domain to it.
Naw rocketchat was just plugging in a blank page, I’ll be putting an actual webpage on it at a later point. I’ll be weighting apache against nginx, I haven’t decided what one yet.
Aha. In that case, it’s probably easiest to settle on apache or nginx, rather than trying to get both working together Apart from the obvious reasons, certbot will tend to assume you’re just using one or the other, and will try to automatically configure things based on that assumption.
Apart from the obvious reasons, certbot will tend to assume you’re just using one or the other, and will try to automatically configure things based on that assumption.