Another certificate showing up on SSL Labs

Help
1

My domain is: dnll.xyz and hockeyjunior.ca
I ran this command: don't remember but can provide config files if needed
It produced this output: see above
My web server is (include version): Apache 2.4.51
The operating system my web server runs on is (include version): openSUSE 15.3
My hosting provider, if applicable, is: my own server
I can login to a root shell on my machine: yes
I'm using a control panel to manage my site: no
The version of my client is: certbot 1.23.0

All right so my SSL certificates are working... however, when checking with SSL Labs for hockeyjunior.ca, for some reason the certificate for dnll.xyz shows up as #2. See here:

https://www.ssllabs.com/ssltest/analyze.html?d=hockeyjunior.ca&hideResults=on
https://www.ssllabs.com/ssltest/analyze.html?d=dnll.xyz&hideResults=on

For dnll.xyz there is correctly just one certificate showing up. Both certificates are supposed to be configured identically with certbot and the cloudflare dns plugin. The host is the same for both websites.

2

That's normal I'd say. The "No SNI" test is to see what your server returns as a default for that IP address, and you can see that yourself by browsing to https://76.64.252.76 and you'll see the default certificate used by your web server is the dnll.xyz one.

If the clients browser uses SNI to supply the correct hostname it wants, it'll get the correct certificate. For the most part all modern clients will do this and you'd only see a problem on old stuff like Windows XP. In practise all websites that share a host have this issue unless they setup one IP address per certificate.

6 Likes
3

Ha, this actually makes a lot of sense. So let's say I would make it so that the IP address doesn't return a certificate, it would not show up anymore for my second domain name?

While it technically doesn't matter too much I'd rather not have people be able to easily figure out all the domain names I own, although there could be engines allowing to reverse search an IP address anyways, but IPs change all the time.

1 Like
4

You can only directly see that one cert using the IP address alone, but yes there are plenty of reverse IP lookup websites that will show which sites all run on the same host.

Another thing you can do is host your domain DNS in Cloudflare (free) which hides your IP address behind their own proxy and also gives you free geographic caching, which generally makes your site faster.

2 Likes
5

I need to look more into the CloudFlare DNS proxy thing, I remember testing it in the past but had issues. I use my personal domain name for other stuff such as VPN, I don't remember if port forwarding (other than 443/80) was compatible at the time, I'll do some more testing.

In the meantime there is no reason for Apache to return anything else than a 404 when someone types my IP address directly in their browser so I'll change this and see what happens.

6

Sure, yes I've not really tried it with special ports, the proxying is optional per hostname. Network ports · Cloudflare Fundamentals docs

2 Likes
7

You could also set up a default server in Apache that responds with a fake self-signed cert for requests other than valid host name on your server

6 Likes
8

You put me on the right path. To avoid Apache warnings, I created a CA and generate a self-signed certificate that won't expire for the next century, then I created a 000-default.conf vhost in Apache with the following:

<VirtualHost _default_:80>
ServerName default
DocumentRoot /some/path
</VirtualHost>

<VirtualHost _default_:443>
ServerName default
DocumentRoot /some/path

SSLEngine on
SSLCertificateFile /etc/ssl/v3_ca/verificationCert.crt
SSLCertificateKeyFile /etc/ssl/v3_ca/verificationCert.key
</VirtualHost>

The certificate must have the ServerName (here, default) in its common name to avoid other Apache warnings. With this, the No SNI certificate does show up for both my domains, but you can't easily "guess" a domain just from the IP. And because my IP changes every time I reboot my modem... it's somewhat obfuscated. Obviously, that doesn't replace Cloudflare's proxy feature.

Of course, my domains might not work correctly with browsers not supporting SNI... not sure if these are still in circulation in 2023.

1 Like
9

Just to comment on this, I use my domain for my VPN as well, so not ideal for my specific usage.

10

Would you even want to test your html, css, scripting ... with such a browser :slight_smile:

2 Likes
11

Are there any left [in any real use]?

1 Like
12

not really

IE6 in general
IE7 or IE8 on Windows XP

Android Browser 2.1-2.3

Chrome 4-5

seems less than 0.05% market share in total

1 Like
13

So... devices that are technologically "ancient".
Such devices would fail for >99% of all Internet sites.
I think they would have stopped using it to access anything over the Internet long ago.
[OR would have found some way to proxy their requests to the Internet]

2 Likes
14

I noticed new Apache errors since I added the self signed certificate. I only get the errors specifically when SSLLabs does its thing, it doesn't happen otherwise in normal usage as far as I know.

AH02042: rejecting client initiated renegotiation
15

Then you should be fine.

2 Likes
16

For which domain name? Because dnll.xyz looks good (no leak). But, hockeyjunior.ca is much different because it uses Cloudflare CDN.

Here is dnll.xyz

echo | openssl s_client -connect dnll.xyz:443 | head
---
Certificate chain
 0 s:CN = dnll.xyz
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug  7 02:09:26 2023 GMT; NotAfter: Nov  5 02:09:25 2023 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256

With no host name (no SNI)
echo | openssl s_client -connect dnll.xyz:443 -noservername | head
---
Certificate chain
 0 s:C = US, ST = CA, O = Internet Widgits Pty Ltd, CN = default
   i:C = US, O = Internet Widgits Pty Ltd
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 14 03:26:55 2023 GMT; NotAfter: Aug 14 03:26:55 2123 GMT

With fake servername (like wierd bot)
echo | openssl s_client -connect dnll.xyz:443 -servername FAKE | head
---
Certificate chain
 0 s:C = US, ST = CA, O = Internet Widgits Pty Ltd, CN = default
   i:C = US, O = Internet Widgits Pty Ltd
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 14 03:26:55 2023 GMT; NotAfter: Aug 14 03:26:55 2123 GMT
3 Likes
17

I switched to proxy for the domain I only use for web purposes (hockeyjunior.ca), the other (dnll.xyz) I'd prefer not to obfuscate the IP address as it's for my homelab and I have multiple uses for it. Anyways.

The error happens specifically when generating a report with SSL Labs for dnll.xyz, no issues with hockeyjunior.ca. It happens when it says "testing compression" on the test.

I also started getting this error as well but not simultaneously:

SSL Library Error: error:SSL routines:ssl3_read_bytes:no renegotiation

In case this is relevant, here is what I did to create a certificate from a new CA:

Initial configuration file /etc/ssl/v3_ca/rootCA_openssl.conf

[ req ]
distinguished_name       = req_distinguished_name
extensions               = v3_ca
req_extensions           = v3_ca

[ v3_ca ]
basicConstraints         = CA:TRUE

[ req_distinguished_name ]
countryName                 = Country Name (2 letter code)
countryName_min             = 2
countryName_max             = 2
countryName_default         = US
organizationName            = Organization Name (eg, company)
organizationName_default    = Internet Widgits Pty Ltd

... and then...

openssl genrsa -out /etc/ssl/v3_ca/rootCA.key 2048
openssl req -new -sha256 -key /etc/ssl/v3_ca/rootCA.key -nodes -out /etc/ssl/v3_ca/rootCA.csr -config /etc/ssl/v3_ca/rootCA_openssl.conf
openssl x509 -req -days 36525 -extfile /etc/ssl/v3_ca/rootCA_openssl.conf -extensions v3_ca -in /etc/ssl/v3_ca/rootCA.csr -signkey /etc/ssl/v3_ca/rootCA.key -out /etc/ssl/v3_ca/rootCA.pem
openssl genrsa -out /etc/ssl/v3_ca/verificationCert.key 2048
openssl req -new -key /etc/ssl/v3_ca/verificationCert.key -out /etc/ssl/v3_ca/verificationCert.csr
openssl x509 -req -in /etc/ssl/v3_ca/verificationCert.csr -CA /etc/ssl/v3_ca/rootCA.pem -CAkey /etc/ssl/v3_ca/rootCA.key -CAcreateserial -out /etc/ssl/v3_ca/verificationCert.crt -days 36524 -sha256

I notice on SSL Labs there is an additional certificate for dnll.xyz under the certificate #2 (no SNI).

image
image1005×876 28.4 KB

Not sure what to make of this.

18

I'll take the easy one now and maybe the other one(s) later

The second cert is expected with your new config. SSL Labs is just showing what happens to a client that does not support SNI. Those see your new self-signed cert you setup. That is entirely normal and expected. I showed the same thing with the openssl commands from my own test server. The end results is that SNI is required for your dnll.xyx domain.

The SSL Labs test for hockey is largely testing the connection to the Cloudflare CDN edge. It terminates HTTPS for the client. Some legit test requests might pass onwards to your origin but any faulty ones would be logged at Cloudflare. And, Cloudflare does not support non-SNI clients as no CDN can really. SSL Labs probably skips that test because of this.

You did not get a cert from a new "CA" (Certificate Authority). You just made a self-signed cert. Which is fine for this purpose.

4 Likes
19

The second cert is expected with your new config.

Sorry, I wasn't clear enough, I meant the certificate #2 is for the no SNI but there is an "additional certificates" tab at the bottom (shown on my picture) with an incomplete chain issues that also shows up. This specific one only shows up after I followed this guide to generate the certificate rather than a single one liner like this:

openssl req -x509 -nodes -days 36525 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

The reason why I went from this one liner to the 6 commands in my previous post with the rootCA_openssl.conf file is to prevent the Apache warning mentionned on SO:

An error occurred (CertificateValidationException) when calling the RegisterCACertificate operation: CA certificate is not valid. The CA certificate does not have the basicConstraints extension as true

Before that, I did not have the new issues with the AH02042 error.

At the end of the day, everything is "working", I just like stuff to be configured properly I guess, I'm a system administrator but I am obviously not specialized by any means in web hosting.

20

Sorry, can't help with that. I use the one-liner self-signed cert on nginx and don't have that weird chain error on SSL Labs for non-SNI clients. And, nginx doesn't error either. I don't think I'd care much that a catch-all connect from a non-SNI client behaved poorly :slight_smile:

That SO thread was for AWS IoT not Apache although the error message text was the same.

I haven't used Apache in a long time but haven't seen any self-signed cert issues. A quick google found the below from a large hosting service that uses that one-liner in their instructions for Apache.

This is about all I care to do about that. Maybe try an Apache forum?

3 Likes