Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
The main domain bearclaw.io is pointed to a different server, so I am not 100% sure if that is the issue.
to see where different certificates are configured in your Apache setup. It looks like a default non-publicly-trusted certificate is still taking precedence over your new Let's Encrypt certificate, for some reason.
/etc/httpd/conf/httpd.conf:SSLCertificateFile /etc/letsencrypt/live/dev.bearclaw.io/cert.pem
/etc/httpd/conf/httpd.conf:SSLCertificateKeyFile /etc/letsencrypt/live/dev.bearclaw.io/privkey.pem
/etc/httpd/conf/httpd.conf:SSLCertificateChainFile /etc/letsencrypt/live/dev.bearclaw.io/chain.pem
/etc/httpd/conf.d/ssl.conf:# Point SSLCertificateFile at a PEM encoded certificate. If
/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:# Point SSLCertificateChainFile at a file containing the
/etc/httpd/conf.d/ssl.conf:# the referenced file can be the same as SSLCertificateFile
/etc/httpd/conf.d/ssl.conf:#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
This is related to various other problems with CentOS Apache defaults that have cropped up over the years, but I suspect the problem is that you have a default VirtualHost (e.g. for _default_) instead of a VirtualHost that specifies a specific servername. So, the default VirtualHost in httpd.conf conflicts with the default VirtualHost in ssl.conf, resulting in the latter taking precedence for some reason, and serving the localhost.crt instead of the Let's Encrypt certificate.
If this hypothesis seems plausible to you, could you change httpd.conf to indicate your server name explicitly? Alternatively, you could make a new .conf file with a new non-default VirtualHost specifically for your site, and then run Certbot again?
You can find more information about specifying names for VirtualHosts in Apache configurations at
That is interesting, but there are some tricky things even about alphabetical order (!) in the CentOS Apache defaults, leading to cases where default certificates were or were not used depending on the alphabetical position of the filename.
VirtualHost configuration:
*:80 dev.bearclaw.io (/etc/httpd/conf/httpd.conf:354)
*:443 is a NameVirtualHost
default server dev.bearclaw.io (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost dev.bearclaw.io (/etc/httpd/conf.d/ssl.conf:56)
port 443 namevhost dev.bearclaw.io (/etc/httpd/conf/httpd.conf:361)
This represents a conflict: you can't explicitly specify the same name and port in two different virtual hosts on the same machine. (Or as @rg305 would say, you can, but Apache will "run at all costs" and just randomly pick one instead of refusing to choose between them—in this case, apparently randomly picking the one with the localhost cert instead of the valid Let's Encrypt cert.)