I installed certbot-auto on CENTOS 6 with apache succesfully.
I ran certbot-auto for a virtual host referring to two domains.
Certbot issued one warning “we were unable to set up enhancement redirect for your server, however, we successfully installed your certificate”. Indeed, http does not redirect. But that’s not the issue here.
And this is in the vhost configuration file (that worked perfect with http):
ServerName ketelaarsbrug.nl
ServerAlias *.bed-and-breakfast-amersfoort.nl *.ketelaarsbrug.nl
DocumentRoot /var/www/www.ketelaarsbrug.nl
The certificates are stored under …/www.ketelaarsbrug.nl/…
What is the problem?
If I specified the wrong domain names with certbot, what should I have specified?
If my vhost configuration is the trouble, what should be in the conf file?
What can I do to fix this?
And … sorry for my ignorance. I have been reading all kinds of documents the last two weeks to get this working smoothly, and nevertheless I failed
Thanks a lot for your help!!
It looks as if you obtained a certificate, but your apache is still using a self signed certificate.
It may be that you just need to restart apache.
If that doesn’t work, can you access the /etc/httpd directory, and then check in the config which SSL derts are being used ( grep -R SSLCertificate * ) they should be ones in /etc/letsencrypt/live/…
The SSLCertificate specified in the conf file does exist in /etc/letsencrypt/live/www.ketelaarsbrug.nl
(note: there is also a ssl.conf and it points to SSLCertificateFile and SSLCertificateKeyFile)
and it turns out that the test complains about the vps domain name:
“
Subject vps40188.public.cloudvps.com
Fingerprint SHA1: 49735438478cb015afea30f9fd3537dfa472d301
Pin SHA256: bg7a3+/CVs+JfBIjVu+yP498poQIrgwCL5nyHkCXt9g=
Common names vps40188.public.cloudvps.com MISMATCH
Alternative names -
Valid from Thu, 10 Nov 2016 19:07:14 UTC
Valid until Fri, 10 Nov 2017 19:07:14 UTC (expires in 11 months and 30 days)
Key RSA 2048 bits (e 65537)
Weak key (Debian) No
Issuer vps40188.public.cloudvps.com Self-signed
Signature algorithm SHA256withRSA
Extended Validation No
Certificate Transparency No
OCSP Must Staple No
Revocation information None
Trusted No NOT TRUSTED (Why?)
”
So, does this mean that the server is using a “self signed certificate”?
If so, I hope you can give me a suggestion on how to fix this.
Thanks!!!
Path #1: Not trusted (path does not chain to a trusted anchor)
Sent by server
Not in trust store vps40188.public.cloudvps.com Self-signed
Fingerprint SHA1: 49735438478cb015afea30f9fd3537dfa472d301
Pin SHA256: bg7a3+/CVs+JfBIjVu+yP498poQIrgwCL5nyHkCXt9g=
RSA 2048 bits (e 65537) / SHA256withRSA
The site responds via http:// but https:// for me responds with the default apache site.
Even if the ssl cert is mismatched… I would normally expect to see your site (same as http)… but with the browser complaining it is an invalid certificate.
In this case, https:// gives me basically a non-existent site – and hence yields the default hosters ssl cert
What files have you got in /etc/letsencrypt/live/www.ketelaarsbrug.nl ? is the certificate in there somewhere ? if not, what folders are in /etc/letsencrypt/live/ ? is there a folder there in which the certificate exists ?
And if so, how can I create a new certificate for other domains running on the same VPS server? Imo this will create a conflict again with the VPS server. Or should I use one cert for all domains?
I’ve got four symbolic links:
…/www.ketelaarsbrug.nl/cert.pem
chain.pem
fullchain.pem
privkey.pem
And they point to certs on
archive/www.ketelaarsbrug.nl/cert1.pem
etc.
The apache conf.d contains two conf files
One for *:.80 without redirecting to https
One create by certbot for *:443 pointing to the above mentioned certs
This shouldn't be necessary - unless you actually use your vps ndomain name for anyone connecting.
You shouldn't need to create a new cert - you already have one for www.bed-and-breakfast-amersfoort.nl and www.ketelaarsbrug.nl (unless you use / redirect from bed-and-breakfast-amersfoort.nl and ketelaarsbrug.nl ... in which case you may need to expand your certificate to include those).
The "symbolic links" in ../www.ketelaarsbrug.nl are the files you need.
If the file created by certbot for *:443 links to those files, then it should be all OK .... Does the config also point to the VPS config files somewhere ? Are you happy to paste your apache config files in pastebin.com ?
Well, it seems most likely that this Apache configuration does not, in fact, control the web server the tests are connecting to, since that server is providing instead a completely different certificate.
You wrote already that you tried restarting Apache, so that's not it. Is it possible you have some other server software, such as a "reverse proxy", a load balancer or similar that answer the HTTPS connection ?
I have no idea. It's a fact however that I cannot use sendmail for the same reason: when I send a mail, the VPS adds the domain vps40188.public.cloudvps.com as the sender and the mail is consequently rejected by gmail and other mail providers.
These files don’t include your VPS cert - I’m guessing there is another file (default-ssl.conf ? ) with that in.
hopefully just adding “SSLEngine on” and then reloading apache should get you working ( it does depend slightly what’s in your other config file though - as to which one it’s using )
Thanks. That’s the file it seems to be using - but should also be using the other file for the domain ( from the settings you have there ).
Can you double check from the processes that it is reloading the updated config properly ( there isn’t an old apache process continuing to run. maybe stop apache completely - confirm it’s stopped and then restart ).
also, does “apachectl -t” (which tests the apache config ) confirm everything is OK.
One difference to my typical configs is the order of the “IfModule” statement shich seems odd in yours. Assuming you have the module though it shouldn’t make a difference.
I get different browser warnings now, meaning that the SSL connection is not working at all:
An error occurred during a connection to www.ketelaarsbrug.nl. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG