Apache多SSL证书互斥致servers.domain1.com证书失效求助

Alright, let's tackle this SSL certificate issue with servers.domain1.com. Since your domain2.com wildcard cert is working fine, the problem likely lies in configuration conflicts, certificate validity, or misconfigured virtual hosts. Here's a step-by-step breakdown to fix it:

The most common culprit here is that your domain2.com wildcard VirtualHost might be prioritized over the servers.domain1.com config, especially if it loads first or has overly broad matching rules.

For Apache: #

• Verify the load order of your site configs (files in /etc/apache2/sites-available/). Configs with lower-numbered prefixes (like 000-domain2.conf) load first and will match requests before later configs. If servers.domain1.com's config has a higher number, it might never get hit.
• Ensure your servers.domain1.com VirtualHost has an explicit ServerName and correct certificate paths:

<VirtualHost *:443>
    ServerName servers.domain1.com
    SSLEngine on
    # Paths to your Let's Encrypt files
    SSLCertificateFile /etc/letsencrypt/live/servers.domain1.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/servers.domain1.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/servers.domain1.com/chain.pem
    
    # Rest of your site configuration (document root, etc.)
</VirtualHost>

• After updating configs, run apache2ctl -S to list all virtual hosts and confirm servers.domain1.com is mapped to the correct config file. Then restart Apache with systemctl restart apache2.

For Nginx: #

• Check your server blocks in /etc/nginx/sites-available/ to ensure servers.domain1.com has an explicit server_name (Nginx matches exact names before wildcards):

server {
    listen 443 ssl;
    server_name servers.domain1.com;

    # Let's Encrypt certificate paths
    ssl_certificate /etc/letsencrypt/live/servers.domain1.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/servers.domain1.com/privkey.pem;

    # Rest of your site configuration
}

• Run nginx -T to view the full active configuration and confirm no other server block (like domain2.com's wildcard) is matching servers.domain1.com. Restart Nginx with systemctl restart nginx.

It's possible the certificate itself doesn't cover servers.domain1.com, or it's expired/corrupted.

• Run this command to inspect the certificate details:

openssl x509 -in /etc/letsencrypt/live/servers.domain1.com/cert.pem -text -noout

• Look for the Subject Alternative Name (SAN) section—make sure it explicitly lists servers.domain1.com. If it's missing, reissue the certificate with Certbot:

certbot certonly --webroot -w /path/to/servers.domain1/webroot -d servers.domain1.com

• Also check the Not Before and Not After fields to confirm the certificate isn't expired.

• Ensure port 443 is being listened on by your web server:

netstat -tulpn | grep :443

You should see apache2 or nginx listed as the process.

• Check your firewall rules to confirm port 443 is open:
  • For Ubuntu/Debian: ufw status
  • For RHEL/CentOS: firewall-cmd --list-all
    If 443 isn't allowed, add it (e.g., ufw allow 443).

Sometimes the problem is on the visitor's end:

• Test servers.domain1.com in a private/incognito browser window to bypass cached certificate data.
• Use curl to debug the SSL handshake directly from the server:

curl -v https://servers.domain1.com

Look for error messages like SSL certificate problem: unable to get local issuer certificate—this means you're missing the Let's Encrypt intermediate chain file (fix by ensuring SSLCertificateChainFile or ssl_certificate uses fullchain.pem).

Double-check that your AlphaSSL wildcard certificate only covers *.domain2.com (not *.com, which would match all .com domains and cause conflicts). Run:

openssl x509 -in /path/to/alphassl/wildcard-cert.pem -text -noout

Verify the SAN section only includes *.domain2.com.

内容的提问来源于stack exchange，提问作者Phil Gibson