Why does the certificate not match when multiple sites share one IP and port? - Certificate Management Service

When multiple HTTPS sites share the same IP address and port, the server cannot determine which certificate to use during the TLS handshake. It falls back to the certificate of the first site bound to that IP and port, causing a mismatch error for all other sites.

This problem occurs when all three of the following are true:

Multiple sites are bound to the same IP address and port on a web server.
The server can distinguish between different host headers in client requests.
An SSL certificate has been requested and installed for each SSL site, but users receive a certificate mismatch error when browsing the sites.

How it works

During a TLS handshake, the server must select the correct certificate before it can decrypt the incoming request. To select the right certificate, it needs the host header — but the host header is inside the encrypted payload. To break this deadlock, the server picks the first site bound to the specified IP and port and uses that site's certificate for all requests on that address. Requests to other sites on the same IP and port are decrypted with the wrong certificate, which causes the mismatch error.

Choose a fix

Select the solution based on your web server:

Web server	Recommended fix	Notes
IIS	Upgrade to IIS 8+ (SNI)	Lowest operational overhead
IIS (legacy, no SNI)	Separate IP addresses or wildcard certificate	Extra cost or domain constraint
Nginx	Configure virtual hosts (SNI-based)	Native SNI support
Apache	Configure virtual hosts (SNI-based)	Requires `SSLStrictSNIVHostCheck off`

IIS

For Internet Information Services (IIS) servers, use one of the following methods.

Upgrade to IIS 8 (recommended)

IIS 8 supports Server Name Indication (SNI), which lets the server read the host header before decryption and select the correct certificate. Upgrade IIS to version 8 or later, then enable SNI. For configuration steps, see SSL Scalability.

Use a wildcard certificate

Use a single wildcard certificate that covers all your sites. For example, a certificate issued for *.aliyundoc.com covers example.aliyundoc.com, demo.aliyundoc.com, and learn.aliyundoc.com. Any request to those sites is decrypted with the same certificate.

This approach works without upgrading IIS, but requires all sites to share a common parent domain.

Bind each site to a different IP address

Assign a separate IP address to each HTTPS site. With no IP overlap, the server identifies each site by its IP address alone, without needing the host header.

This eliminates the conflict but requires additional IP addresses, which increases cost.

Bind each site to a different port

Bind each HTTPS site to a unique port on the same IP address, using the format [$Domain]:[$Port].

[$Domain] is the domain name of the site and [$Port] is the assigned port. Users must include the port number in the URL when accessing the site.

Nginx

On Nginx, configure a separate server block (virtual host) for each HTTPS site. Nginx natively supports SNI and selects the correct certificate based on the server_name value.

Log in to the Nginx server and open the Nginx configuration file.
[$Nginx_Dir] is the Nginx installation directory. The default is /usr/local/nginx.
```
vim [$Nginx_Dir]/conf/nginx.conf
```

Add a server block for each HTTPS site.

server {
    listen 443;
    server_name [$Domain1];
    ssl on;
    ssl_certificate [$Certificate_Path1];
    ssl_certificate_key [$Key_Path1];
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers [$Ciphers_Suite1];
    ssl_prefer_server_ciphers on;
    location / {
        root html;
        index index.html index.htm;
    }
}
server {
    listen 443;
    server_name [$Domain2];
    ssl on;
    ssl_certificate [$Certificate_Path2];
    ssl_certificate_key [$Key_Path2];
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers [$Ciphers_Suite2];
    ssl_prefer_server_ciphers on;
    location / {
        root html;
        index index.html index.htm;
    }
}

Replace each placeholder with the actual values for your sites.

Apache

On Apache, configure a VirtualHost block for each HTTPS site and enable SNI.

Log in to the Apache server and open the SSL configuration file.
[$Apache_Dir] is the Apache installation directory. The default is /etc/httpd. If ssl.conf is not found, install the SSL module first by running yum install mod_ssl -y. After you enable SNI for Apache, add the SSLStrictSNIVHostCheck off parameter.
```
vim [$Apache_Dir]/conf.d/ssl.conf
```
Add a VirtualHost block for each HTTPS site.
- If a single certificate covers both www.example.com and example.com (for example, a free Alibaba Cloud certificate), use ServerName example.com and ServerAlias www.example.com. Otherwise, the www variant may be inaccessible. - [$Certificate_Chain1] and [$Certificate_Chain2] are the paths to the intermediate certificate bundle for each site. - In Apache 2.4.8 and later, SSLCertificateChainFile is replaced by SSLCACertificatePath.
```
Listen 443
NameVirtualHost *:443
<VirtualHost *:443>
  ……
  ServerName [$Domain1]
  SSLCertificateFile     [$Certificate_Path1];
  SSLCertificateKeyFile  [$Key_Path1];
  SSLCertificateChainFile  [$Certificate_Chain1];
  ……
</VirtualHost>
<VirtualHost *:443>
  ……
  ServerName [$Domain2]
  SSLCertificateFile     [$Certificate_Path2];
  SSLCertificateKeyFile  [$Key_Path2];
  SSLCertificateChainFile  [$Certificate_Chain2];
</VirtualHost>
```

What's next

After applying your chosen fix, verify that each site loads with the correct certificate by opening it in a browser and inspecting the certificate details.

For certificate installation instructions, see:

Applicable to

Certificate Management Service