Certificate Management Service:Why did my SSL certificate deployment fail?

Misconfigured paths or a missing service restart are among the most common causes of deployment failures.

• Verify that the certificate file path and name in the configuration file match the actual location on disk. The following NGINX example shows the relevant fields:

  server {
      # Port 443 is the default port for HTTPS
      listen 443 ssl;
      server_name example.com;
  
      # Replace these paths with your actual certificate and private key paths
      ssl_certificate /etc/nginx/ssl/example.com.crt;
      ssl_certificate_key /etc/nginx/ssl/example.com.key;
  
      # Other configuration...
  }

• Confirm the configuration file was saved after you edited it.

• Restart the web server to apply the changes:

  • NGINX: ``bash sudo nginx -s reload ``

  • Apache HTTP Server: ``bash sudo systemctl restart httpd ``

1. Log on to the Certificate Management Service console.

2. In the left navigation pane, choose Certificate Management > SSL Certificate Management.

3. On the SSL Certificate Management page, locate your certificate and check:

   • Status is Issued

   • Bound Domains lists the correct domain

If the certificate has expired, renew it. For renewal steps, see SSL Certificate Renewal and Expiration Handling.

If you're using a self-signed certificate, the browser will show a warning because self-signed certificates aren't trusted by default. To check the trust status in Google Chrome:

1. Open the site in Chrome.

2. Click the icon in the address bar. No warning icon means the browser trusts the certificate. A red icon means it doesn't.

1. Click the icon for details. If the certificate isn't trusted, the certificate information window shows a warning.

If you're using a commercial certificate, confirm it was issued by a trusted Certificate Authority (CA). To verify in Chrome:

1. Click the icon in the address bar.

2. Click Connection is secure.

3. Click Certificate (Valid). A trusted CA-issued certificate shows no warning.

In the certificate information window, find the Issuer field and confirm the common name (CN) and organization name (O) match a well-known CA.

If DNS doesn't point to the correct server IP, HTTPS connections go to the wrong host and the certificate won't match.

1. Log on to the Alibaba Cloud DNS console.

2. On the Authoritative DNS Resolution page, under the Authoritative Domain Names tab, click the domain name to open the Settings page.

1. Click Add Record and verify the Record Value matches your server's IP address. If it doesn't match, click Edit to update it.

DNS changes can take time to propagate. If you recently updated DNS settings, clear the local DNS cache and retry.

Browsers can cache old certificate data. Clear the browser cache and revisit the site, or open the site in incognito mode (Chrome) or InPrivate mode (Microsoft Edge) to bypass the cache.

Why this matters: Browsers verify the full chain from the root certificate down to your server certificate. A missing intermediate certificate causes untrusted certificate warnings, especially on Android browsers that don't support fetching intermediate certificates via Authority Information Access (AIA) URLs.

The certificate chain must be ordered as follows:

-----BEGIN CERTIFICATE-----
Website certificate
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
CA intermediate certificate
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
CA root certificate
-----END CERTIFICATE-----

The chain order is website certificate > CA intermediate certificate > CA root certificate. An intermediate certificate chain can have multiple layers.

View the certificate chain in Chrome

1. Click the icon in the address bar, then click Connection is secure.

2. In the pop-up window, click Certificate is valid.

3. Click Details and check the Certification hierarchy.

Why this matters: When you generate a Certificate Signing Request (CSR), a private key is created at the same time. Only the matching private key works with that certificate. Uploading a mismatched private key causes the HTTPS handshake to fail.

To verify the match on a Linux system:

1. Log on to your ECS instance and go to the certificate installation directory:

   # Replace /ssl with your actual certificate installation path
   cd /ssl

2. Get the MD5 hash of the certificate's public key:

   # Replace your_certificate.pem with your actual PEM file name
   sudo openssl x509 -in your_certificate.pem -noout -pubkey | openssl md5

3. Get the MD5 hash of the private key's public key:

   # Replace your_private_key.key with your actual private key file name
   sudo openssl rsa -in your_private_key.key -pubout | openssl md5

4. Compare the two MD5 hashes. If they match, the private key corresponds to the certificate.

If the private key is lost or corrupted, generate a new key pair and request a new certificate.

The certificate format and cipher suite must be compatible with mainstream browsers.

• Use a trusted CA. Mainstream browsers automatically trust certificates from well-known CAs.

• Use X.509 format. Verify the certificate format with the following command:

  # Replace /ssl/cert.pem with your actual certificate file path
  sudo openssl x509 -in /ssl/cert.pem -text -noout

  If the certificate is in X.509 format, the command returns version, serial number, signature algorithm, issuer, validity period, and public key details:

  Certificate:
      Data:
          Version: 3 (0x2)
          Serial Number:
               01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef
          Signature Algorithm: sha256WithRSAEncryption
          Issuer: C = US, O = DigiCert Inc
          Validity
              Not Before: Jan 17 00:00:00 2025 GMT
              Not After : Jan 17 23:59:59 2026 GMT
          Subject: CN = example.com
          Subject Public Key Info:
              Public Key Algorithm: rsaEncryption
                  RSA Public-Key: (2048 bit)
                  ......

  Save the certificate and intermediate certificate chain in PEM format (.crt or .pem files).

• Use modern cipher suites. Configure the server to use TLS 1.2 or TLS 1.3, and disable insecure protocols and algorithms: SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, RC4, and 3DES.

• Test the site on multiple browsers and devices to confirm compatibility.

The web server process must be able to read the certificate files. If permissions are too restrictive, the server can't load the certificate.

To check and set permissions on a Linux server:

1. View the directory permissions:

   • The first character (d) indicates a directory

   • The next three characters (rwx) are the owner's permissions: read, write, execute

   • The middle three (r-x) are group permissions: read, execute

   • The last three (r-x) are permissions for other users: read, execute

   # Replace /ssl with your actual certificate directory path
   sudo ls -ld /ssl

   The output looks similar to drwxr-xr-x, where:

2. Confirm read (r) and execute (x) permissions exist for the user or group running the web server. The execute permission on a directory allows users to enter it (for example, with cd).

3. (Optional) To update permissions, run:

   # Replace /ssl with your actual certificate directory path
   sudo chmod 750 /ssl

   The 750 permission grants the owner read, write, and execute access; the group read and execute access; and no access to other users.

Website implementations vary. Review your web server and application log files for SSL-related error messages to identify the root cause. If the issue persists, contact your account manager.