Join Log in
Score:0
Adrien Hingert avatar Server

SSL certificate not working for www subdomain on multiple domain setup

us flag
Adrien Hingert

I have a LAMP server running CentOS Stream 8 and Apache 2.4.37. On this I have three domains (let's call them example.com, example.net & example.org). I have SSL certificates for each domain + the www subdomain.

They share the same codebase (the only difference being the defalt langauge) so they share the same /var/html/www folder and there is no specific domain level configuration in the /etc/httpd/conf/httpd.conf file - the ServerName is example.org:80

I do have a specific configuration in the /etc/httpd/conf.d/ssl.conf file. Here following is the relevant excerpt - there's a <VirtualHost *:443> part for each domain.

NameVirtualHost *:443

<VirtualHost *:443>
DocumentRoot "/var/www/html"
ServerName example.com:443

ErrorLog logs/ssl_example_com_error_log
TransferLog logs/ssl_example_com_access_log
LogLevel warn

SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

SSLCertificateFile /etc/pki/tls/certs/example_com.crt
SSLCertificateKeyFile /etc/pki/tls/private/example_com.key
SSLCACertificateFile /etc/pki/tls/certs/example_com.ca-bundle
</VirtualHost>

The SSL certificate for each domain works for the main domain, but only works for the www subdomain of example (which is the first listed) in the ssl.conf file. So if I try to access https://www.example.net or https://www.example.org, I get a Connection not secure and Warning: Potential Security Risk Ahead from the browser.

What works:
https://example.com
https://example.net
https://example.org
https://www.example.com

What doesn't work:
https://www.example.net
https://www.example.org

I cannot find any hint as to what could be happening in the logs. Does anybody have an idea where I could be looking?

I've tested and whatever domain's VirtualHost section is listed first is the one for which the www SSL works.

45
1 + 4
www
Romeo Ninov avatar
in flag
Romeo Ninov
Have you check the CN (Common Name) of certificate itself?
1
Reply
Adrien Hingert avatar
us flag
Adrien Hingert
@RomeoNinov Sorry, I don't understand what you mean
0
Reply
Adrien Hingert avatar
us flag
Adrien Hingert
Thank you for the edit, @EsaJokinen
0
Reply
jp flag
Esa Jokinen
@RomeoNinov _Common Name_ (CN) won't have both the apex and www covered at the same time, so checking it isn't quite helpful. It's the _Subject Alternative Name_ (SAN) extension that matters.
2
Reply
Score:1
avatar Server
jp flag
Esa Jokinen

Assuming the certificates are correct, there certainly is a detail in your configuration that explains this behaviour. From Apache Virtual Host Matching, the emphasis is mine:

If the connection is using SSL, the server supports Server Name Indication, and the SSL client handshake includes the TLS extension with the requested hostname, then that hostname is used below just like the Host: header would be used on a non-SSL connection. Otherwise, the first name-based vhost whose [IP] address matched is used for SSL connections. This is significant because the vhost determines which certificate the server will use for the connection.

Your <VirtualHost *:443> blocks are missing ServerAlias directives for the www subdomains. Therefore, the first VirtualHost is used as a default name based virtual host, instead.

Furthermore, the ServerName could be used without the optional [:port] as there is no need to distinguish the virtual hosts by ports.

Also notice that SSLCACertificateFile is for client authentication:

This directive sets the all-in-one file where you can assemble the Certificates of Certification Authorities (CA) whose clients you deal with. These are used for Client Authentication. Such a file is simply the concatenation of the various PEM-encoded Certificate files, in order of preference.

The filename example_com.ca-bundle suggests you might have confused this with (deprecated) SSLCertificateChainFile; since 2.4.8 the SSLCertificateFile

may also include intermediate CA certificates, sorted from leaf to root.

An example with a macro that can reduce the copy-paste configuration as well as handle the redirects from HTTP to HTTPS:

NameVirtualHost *:80
NameVirtualHost *:443

<Macro VHost $domain $tld>
    <VirtualHost *:80>
        ServerName $domain.$tld
        ServerAlias www.$domain.$tld
        Redirect permanent / https://$domain.$tld/
    </VirtualHost>

    <VirtualHost *:443>
        ServerName $domain.$tld
        ServerAlias www.$domain.$tld

        DocumentRoot "/var/www/html"

        ErrorLog logs/ssl_$domain_$tld_error_log
        TransferLog logs/ssl_$domain_$tld_access_log
        LogLevel warn

        SSLEngine on
        SSLProtocol all -SSLv2
        SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

        SSLCertificateFile /etc/pki/tls/certs/$domain_$tld.crt
        SSLCertificateKeyFile /etc/pki/tls/private/$domain_$tld.key
    </VirtualHost>
</Macro>

Use VHost example com
Use VHost example net
Use VHost example org
+ 2
Adrien Hingert avatar
us flag
Adrien Hingert
Brilliant, this worked. Thank you very much!
0
Reply
jp flag
Esa Jokinen
I noticed another potential problem and updated my answer to cover it.
1
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.