Server: Jessie+Apache2, backports, installation of Cerbot and cerbot --apache worked smooth.
https://www.ssllabs.com/ssltest/analyze.html?d=owncloud.august.de leads to all green, overall rating A.
However, when I delete all history from clients Firefox and delete regarding security exceptions, I still get “Insecure …”
What do I have not understood?
Kind Regards
Rolf
When I run SSLLABS on your domain name, I also get an “A”, but if you scroll down you will see issues.
Common names - INVALID
Alternative names -
Valid from Sat, 26 Sep 2015 18:38:50 UTC
Valid until Sun, 25 Sep 2016 18:38:50 UTC (expired 7 months and 9 days ago) EXPIRED
Check to make sure you are pointing at all the correct keys/certificates, and maybe check your certificate chain.
I used to run with a locally created certificate. Seems that it is still active (certbot seems to have nothing done about it).
my owncloud.august.de.conf file in apache2/sites-available holds the lines
SSLCertificateFile /etc/ssl/localcerts/apache.pem
SSLCertificateKeyFile /etc/ssl/localcerts/apache.key
In /etc/letsencrypt/archive/owncloud.august.de i found the certificates
cert1.pem chain1.pem fullchain1.pem privkey1.pem
Maybe these are the ones to use - but which of them. I’ll try cert1.pem and privkey1.pem
There is a very odd configuration situation here, which is that when the client does not requesting a name with SNI, your server sends the valid Let’s Encrypt certificate for owncloud.august.de, while when the client does request the server owncloud.august.de, your server sends the self-signed test certificate!
openssl s_client -connect owncloud.august.de:443 # no servername requested; correct certificate returned
openssl s_client -servername owncloud.august.de -connect owncloud.august.de:443 # correct servername requested; incorrect certificate returned
This is the exact reverse of the configuration problem that we normally see in this situation!
Please do not use chain1.pem and privkey1.pem. Their contents are identical to the live versions but don’t auto-update. Please use the live versions (live/chain.pem or live/fullchain.pem and live/privkey.pem) instead.
I use acme.sh myself, but with certbot, use the symbolic links in /etc/letsencrypt/live Certbot should update those links when you renew.
SSLCertificateFile should point to cert.pem
SSLCertificateKeyFile should point to privkey.pem
and you should add SSLCACertificateFile and point that to fullchain.pem
I hope this helps
Maybe what happened here is that you (or the OwnCloud installer) copied the existing HTTPS configuration from the systemwide default configuration file, which still used the self-signed certs, into the domain-specific configuration file. Then when you obtained the Let's Encrypt cert, you configured it in the systemwide configuration file but not in the domain-specific one. Hence your system default is to return the Let's Encrypt certificate, yet when a connection requests your specific domain name (which almost all browsers will do in practice almost all of the time), the self-signed cert is returned.
You should be able to fix this by editing the file you mentioned above and changing the references to /etc/letsencrypt/owncloud.august.de/live/fullchain.pem and /etc/letsencrypt/owncloud.august.de/live/privkey.pem or similar.
This is not the right directive; it does something completely different.
That's it. Thank you for the hint TheEggman. "certbot --apache" had done nothing about my site-conf file sites-available/owncloud.august.de.conf. Just installed the certificats in /etc/letsencrypt... Manually exchanging the path to the certificate in the apache conf file solved the problem.
My apache conf file now contains:
SSLCertificateFile /etc/letsencrypt/archive/owncloud.august.de/cert1.pem
SSLCertificateKeyFile /etc/letsencrypt/archive/owncloud.august.de/privkey1.pem
Again - thank you for the help. I was looking for years for such a solution for my private family site.
Rolf
@ngong, I’m glad your site is working now, but there are two things that might lead you into trouble in the future.
① As I mentioned above, if you use archive, your certificates won’t autoupdate when you use certbot renew. If you use live, they will.
② You should also provide the chain certificate by specifying fullchain.pem instead of cert.pem (or for Apache 2.2, add SSLCertificateChainFile chain.pem). Missing this will not cause problems with desktop browsers that have visited other Let’s Encrypt sites, because they have the certificate in question cached inside the browser, but it will cause problems with other browsers that don’t cache intermediate certificates or that haven’t visited a Let’s Encrypt site before, such as many mobile device browsers.
Your are right schoen. Did not think about it. Now it works with
SSLCertificateFile /etc/letsencrypt/live/owncloud.august.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/owncloud.august.de/privkey.pem
as well as good.
Great! In that case you will probably be able to renew later with certbot renew (which you can also run frequently from cron, if you like, so it will renew automatically when it’s less than 30 days from expiry).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.