I’ve made several attempts to get a correct certificate, but don’t seem to be able to successfully. I’ve attempted before and after setting RDNS for my linode box, in between reboots, manually setting the hostname, nothing seems to produce the correct certificate.
This command: certbot -vvv -a dns-linode -i apache --cert-name realm-peach.com -d "*.realm-peach.com" -d realm-peach.com --server https://acme-v02.api.letsencrypt.org/directory
This output: I don’t have the output as this was yesterday, however, it appeared to have no errors. I reset the webserver after.
My domain is: realm-peach.com
My web server is: Apache 2.4.6
The operating system: CentOS 7
My hosting provider: Linode
I can login to root: yes
Control panel: No
Client version: certbot 0.31.0
But Apache isn’t using any of them. It’s using a self-signed certificate instead.
Can you show us what “certbot certificates” or “sudo certbot certificates” shows?
Can you also check all your Apache configuration files to see what SSLCertificateFile, SSLCertificateChainFile and SSLCertificateKeyFile directives are being used?
“apachectl -t -D DUMP_VHOSTS” or “sudo apachectl -t -D DUMP_VHOSTS” should be able to list all of the virtual hosts configured.
The default ssl.conf file is sometimes known to conflict with other virtual hosts. That might be what’s happening here, or it could be something else.
On CentOS, it apparently matters whether your hostname comes before or after ssl.conf alphabetically (!!). @joohoi has created a fix for this but there are other workarounds possible.
Thank you for the hint. I’m sniffing around these files now, but you are correct it does appear to be not overriding the certificate for the vhost properly.
apachectl -t -D DUMP_VHOSTS
VirtualHost configuration:
*:80 realm-peach.com (/etc/httpd/conf/httpd.conf:133)
*:443 is a NameVirtualHost
default server realm-peach.com (/etc/httpd/conf.d/ssl.conf:36)
port 443 namevhost realm-peach.com (/etc/httpd/conf.d/ssl.conf:36)
port 443 namevhost realm-peach.com (/etc/httpd/conf/httpd-le-ssl.conf:2)
wild alias *.realm-peach.com
---------------------------------------------------------------------------
grep -i -r "SSLCertificate" /etc/httpd
/etc/httpd/conf/httpd-le-ssl.conf: SSLCertificateFile /etc/letsencrypt/live/realm-peach.com/cert.pem
/etc/httpd/conf/httpd-le-ssl.conf: SSLCertificateKeyFile /etc/letsencrypt/live/realm-peach.com/privkey.pem
/etc/httpd/conf/httpd-le-ssl.conf: SSLCertificateChainFile /etc/letsencrypt/live/realm-peach.com/chain.pem
/etc/httpd/conf.d/ssl.conf: SSLCertificateFile /etc/pki/tls/certs/localhost.crt
/etc/httpd/conf.d/ssl.conf: SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
/etc/httpd/conf.d/ssl.conf: #SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
What am I missing? It appears the webserver is still serving the old file, and I’m guessing it’s because of that error, but I don’t know enough of this side of server building to know what to do next.
Sorry, I’m a bit late in the party. The upcoming fix is rather simple, and you can do it easily manually: just move the LoadModule ssl_module ... line from ssl.conf to the beginning of /etc/httpd/conf/httpd.conf.
The reason that this is happening is that in the default CentOS 6 installation, Apache reads all configuration files : /etc/httpd/conf.d/*.conf.
The files are read in aplhabetically sorted order. When a VirtualHost directive is wrapped in <IfModule mod_ssl.c> directive, it gets ignored if it’s read before the LoadModule directive… which then again comes in ssl.conf, which is pretty late in the alphabetic sort order.
Interesting. Attempted that, but does not seem to have solved the problem. Also, I’m still receiving the same RSA certificate configured for realm-peach.com:443 does NOT include an ID which matches the server name error message.
I just realized that it’s not CentOS 6 we’re talking about here. CentOS 7 does not have the same include order issue with LoadModule. There’s something else in play here.
I notice in your DUMP_VHOSTS output that ssl.conf contains a virtualhost for realm-peach.com. You should probably delete that vhost or change it to an unrelated domain name.