Hi, I will not repeat my entire question here, because I already posted on serverfaul, so If anyone can help me with this issue, I will be very thankful:
Try https://www.ssllabs.com/ssltest/
It might show some detail you’ve missed/overlooked.
1 Like
hi @als
Did you do any research about what the error means?
I don't like this stanza as chain.pem is a combination of the certificate and the intermediate
SSLCertificateChainFile /etc/letsencrypt/live/mywebsite/chain.pem
have a look at this article: http://openssl.6102.n7.nabble.com/quot-SSL3-GET-RECORD-wrong-version-number-quot-td8310.html
Specifically:
(only TLS1 enabled, TLS1 client_hello sent to begin handshake)
$ openssl s_client -connect noded:443 -tls1
CONNECTED(00000003)
17373:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:288:
Andrei
It's valid Apache configuration, though obsolete. chain.pem just contains the intermediate(s). fullchain.pem contains the certificate and intermediate(s).
Apache 2.4.26 is new enough to support "SSLCertificateFile /etc/letsencrypt/live/mywebsite/fullchain.pem", but it's not required.
I’m a bit confused, since I’m running a shared hosting, whenever I run:
openssl s_client -connect second-website:443
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = mymainpage.com
verify return:1
Reverse lookup of server IP will return:
nslookup 89.2*.*.*
Non-authoritative answer:
name = mymainpage.com.
The main page virtualhost looks like this:
SSLCertificateFile /etc/letsencrypt/live/mainpage/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mainpage/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/mainpage/chain.pem
And If I disable that with # all of my other websites will not work. Why?
I’m not sure exactly which behaviors you see are wrong in what way, but two thoughts:
For the s_client -connect, be sure to add -servername second-website to match browser behavior with SNI.
For the commenting-out, it’s not generally effective to just comment out those lines if the surrounding stanza says to listen on port 443, because that could result in a non-HTTPS-capable (HTTP-only) listener on port 443. The SSLCertificate directives (and SSLEngine on, which is included in the Include there) are necessary when listening on port 443.
I’dont understand one thing, if I disable SSL from my main page where all other websites are hosted, non of other websites will work.
#SSLCertificateFile /etc/letsencrypt/live/*.0001/cert.pem
#SSLCertificateKeyFile /etc/letsencrypt/live/*.0001/privkey.pem
#Include /etc/letsencrypt/options-ssl-apache.conf
#SSLCertificateChainFile /etc/letsencrypt/live/*.0001/chain.pem
So if I try to visit second hosted page it will return:
Secure Connection Failed
Why?
@als, my previous reply was meant to answer that:
When you comment out those lines, you are still listening on port 443 with that server configuration, which is no longer appropriate to do if you aren't using HTTPS.
So that is normal behavior if commenting-out SSL for website A, will cause that SSL on website B doesn’t work?
If you “comment out SSL” in a stanza that listens on port 443, it causes a direct conflict in your configuration where you are telling Apache “use HTTPS on port 443, and use HTTP on port 443”. Part of the process of “commenting it out” to avoid creating an error should also be to change the stanza to listen on port 80 instead of port 443.
I understand you, but if I comment-out from website B in a same way how I did in previous scenario - all other websites will work normally using HTTPS - except website B where I’m getting:
Your connection is not secure
The owner of website has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website.
websiteB uses an invalid security certificate. The certificate is only valid for the following names: websiteA, www.websiteA Error code: SSL_ERROR_BAD_CERT_DOMAIN
In that case you might have a redirect configured from the HTTP version of the site to the HTTPS version of the site, or perhaps have sent an HSTS record telling browsers that the site is mandated to be HTTPS, or have a link or bookmark sending you to the HTTPS version instead of the HTTP version.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.