Common Pitfalls in Configuring HTTPS for Apache, IIS, and Tomcat

The same certificate file requires completely different configuration methods on different servers, and each has its own pitfalls. Nginx experience is basically useless for Tomcat—it doesn’t read .pem files at all.

Below are the configuration methods and common issues for each server type.

Preparation: Required Formats for Each Server

# Generate PFX (for IIS, requires private key + certificate)
openssl pkcs12 -export -out cert.pfx 
  -inkey privkey.pem -in fullchain.pem -certfile fullchain.pem

# Generate PKCS12 (for Tomcat, recommended format)
openssl pkcs12 -export -out keystore.p12 
  -inkey privkey.pem -in fullchain.pem -name tomcat

Apache

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on

    # Version differences matter here (see below)
    SSLCertificateFile      /path/fullchain.pem
    SSLCertificateKeyFile   /path/privkey.pem
</VirtualHost>

Pitfall: Two Ways to Configure the Certificate Chain

# This line is only needed for older versions (< 2.4.8)
SSLCertificateChainFile /path/chain.pem

# Check version
apachectl -v
httpd -v

Symptoms of wrong version handling: Adding SSLCertificateChainFile in newer versions will trigger a deprecation warning; omitting it in older versions results in an incomplete certificate chain.

# Verify
openssl s_client -connect example.com:443 -servername example.com 
  -verify_return_error </dev/null 2>/dev/null | grep -i 'verify return'

IIS

Steps

1. Import the certificate into the Computer Account (not the current user) — this is critical
2. Add an HTTPS binding to the site and select the imported certificate
3. If multiple sites exist on one server, ensure SNI is enabled

Common Pitfalls

# Must include private key when exporting PFX, and remember the password
openssl pkcs12 -export -out cert.pfx 
  -inkey privkey.pem -in fullchain.pem
# You will be prompted to set an export password, which is needed for IIS import

Tomcat

Steps

# ① Generate Keystore (PKCS12 recommended)
openssl pkcs12 -export -out keystore.p12 
  -inkey privkey.pem -in fullchain.pem -name tomcat

# ② Place in Tomcat directory (e.g., conf/)
# ③ Modify server.xml

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" SSLEnabled="true">
    <SSLHostConfig>
        <Certificate certificateKeystoreFile="conf/keystore.p12"
                     certificateKeystorePassword="password"
                     certificateKeystoreType="PKCS12"
                     type="RSA" />
    </SSLHostConfig>
</Connector>

# View keystore contents using keytool (confirm successful import)
keytool -list -keystore keystore.p12 -storetype PKCS12

# Older Tomcat versions used JKS format with different config syntax
# certificateKeystoreType="JKS"

Common Pitfalls

Incomplete chain is most common in Tomcat: When generating P12 with openssl, you must use -in fullchain.pem. If you only use a single certificate file, the intermediate certificates will not be included.

Universal Verification (Applies to All Three)

# Chain integrity (must return 0)
openssl s_client -connect example.com:443 -servername example.com 
  -verify_return_error </dev/null 2>/dev/null | grep -i 'verify return'

# Validity period
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null 
  | openssl x509 -noout -dates

# TLS version
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

# Port reachability
nc -zv example.com 443

Decision Tree

Configure HTTPS
├─ Apache
│  ├─ ≥ 2.4.8 → Merge cert chain into SSLCertificateFile
│  └─ < 2.4.8 → Use SSLCertificateChainFile separately
├─ IIS
│  ├─ Convert to PFX first (must contain private key)
│  ├─ Import to "Computer Account"     ← Most common error
│  └─ Enable SNI for multi-site
├─ Tomcat
│  ├─ Convert to Keystore (PKCS12 recommended)
│  ├─ Import using fullchain, otherwise chain is incomplete ← Most common error
│  └─ Ensure JKS / PKCS12 type matches config
└─ Verify all three
   └─ Return code for -verify_return_error must be 0

Scenario Analysis: Same Certificate, Different Results Across Servers

Phenomenon: A certificate for the same domain deploys perfectly on one web service,
but shows an “untrusted” warning when moved to another. The certificate file itself hasn’t changed.

1. First, confirm the difference isn’t in the certificate itself → Since the same file works on one service, the certificate is fine. The issue lies in “how it’s handed over to the service”.
2. Check each service’s configuration requirements one by one → Some services require the certificate and private key in the same file, while others require them split.
3. Check if intermediate certificates are included → Some services have specific parameters for intermediate certs; they don’t rely on concatenation.
4. Verify strictly one by one → Don’t skip this step just because “another service works”.
5. Confirm reload vs. restart → Reload maintains existing connections, suitable for online adjustments.
6. Test each service type individually → Final confirmation should be based on normal returns from every service.

# Strict verification: Applies to all types, results must be consistent
echo | openssl s_client -connect example.com:443 -servername example.com 
  -verify_return_error 2>&1 | grep -E 'Verify return code|depth'

# Common differences between services:
# Nginx   —— Site cert and intermediate cert merged in one file, separate private key path
# Apache  —— Cert, private key, and intermediate cert each have their own config item
# Tomcat  —— Usually imports to keystore first, then configures connector

# Reload (does not disconnect existing connections)
nginx -t && systemctl reload nginx
apachectl configtest && systemctl reload httpd

# Check behavior on listening ports
curl -sS -o /dev/null -w '%{http_code}n' https://example.com/

Root Cause: Different services have different requirements for organizing certificate files.
The certificate itself is the same; the problem lies in “how the material is handed over to the service”.

Two key points to remember:

• Do not reuse configuration habits when switching service types.
  First confirm if the target service needs merged files or separate files, and which parameter handles intermediate certificates.
• Strictly verify again every time you switch a service.
  “It worked on another service” is not evidence; verification must target the current object.

8 Common Pitfalls

1. IIS imported to User Account: Certificate not visible during binding.
2. PFX lacks private key: Cannot be used after import.
3. Tomcat generates Keystore with single certificate: Incomplete chain.
4. Tomcat type mismatch: JKS and PKCS12 must match.
5. Apache version mismatch with chain config: Either errors out or has incomplete chain.
6. IIS multi-site without SNI: Can only use one certificate.
7. Using only browser verification: Browsers auto-complete chains, hiding issues.
8. Firewall not allowing 443: Configuration is correct but inaccessible.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Market (service providers include our store and peers, provided for reference only, not fictional tickets from this site):

1****b Rating: 5.0 2022-01-05 16:21 Very serious and responsible d****x Rating: 5.0 2021-12-02 11:34 Easy to use Yi****ji Rating: 5.0 2020-07-08 14:04 Configured well. Thanks Zhi****si Rating: 5.0 2020-07-08 11:25 Fast configuration. Good p****t Rating: 5.0 2020-02-11 15:08 None 1

h****6 Rating: 5.0 2022-06-07 09:37 b****h Rating: 5.0 2022-04-01 15:11 Che****che Rating: 5.0 2022-02-25 11:24

2****0 Rating: 5.0 2022-11-03 14:39 j****1 Rating: 5.0 2022-04-25 10:07 y****6 Rating: 5.0 2022-04-19 16:27 Chong****0 Rating: 5.0 2021-11-11 22:29 OK h****3 Rating: 5.0 2021-09-07 11:19 Easy to use 8****0 Rating: 5.0 2021-07-22 11:29 Extremely fast response, completed quickly! h****3 Rating: 5.0 2020-09-07 14:05 Timely configuration. 1