SSL Certificate Deployment: From Application to Nginx Configuration in Docker

Overview

This article is part 27 of the "Deploy Yourself to the Internet" series. It explains why HTTPS matters beyond the browser lock icon — it affects access security, browser warnings, admin login, modern Web capabilities, search ranking, and sharing experience. For a long-running blog, the site must be accessible via trusted connections.

Complete Chain

The end-to-end flow is: apply for certificate → complete domain validation → download certificate → place on server → configure Nginx → check configuration → reload service → verify HTTPS works . The example uses Alibaba Cloud (domain purchased there), but the process is similar across providers.

Certificate application succeeds, but Nginx path is wrong → HTTPS still fails; Nginx config is correct, but security group blocks 443 → external access fails; 443 works, but certificate domain mismatches → browser still warns.

At minimum, the following must hold:

Certificate covers the current domain

Certificate issued by a browser-trusted CA

Certificate not expired

Nginx can read certificate and private key

Port 443 reachable

HTTP redirects to HTTPS

Practical Steps (Alibaba Cloud Example)

Purchase Certificate

Search Alibaba Cloud for Digital Certificate Management Service . Two types:

Official certificates : production-grade, strong security, high compatibility, SLA-backed, support single-domain, wildcard, multi-domain, DV/OV/EV validation.

Personal test certificates : for test environments and personal developers, cheap, single-domain only, no SLA, 20 free certificates per user per year.

Production workloads should use official certificates; personal practice can use free test certificates.

Apply for Certificate

After purchase, go to Certificate Management → view purchased certificates. Status shows Pending Application. Fill basic info, verify email and phone to complete application.

Common methods: cloud vendor certificate services, CA consoles, Let's Encrypt, and ACME tools like acme.sh and Certbot. First-timers should use the cloud console for a more visual experience. Regardless of platform, the core is proving you control the domain.

Domain Validation

Two common methods: DNS validation and file validation. DNS validation: add a TXT or CNAME record as required.

File validation: place a specified file at a specified web path.

For sites not yet deployed, DNS validation is easier — only requires control over DNS resolution. Add the record per platform instructions, then wait for propagation.

Verify with commands:

nslookup -type=TXT _acme-challenge.blog.aicultiv.com
dig TXT _acme-challenge.blog.aicultiv.com

If the expected record value appears, return to the certificate platform to continue validation.

If validation fails, do not immediately re-apply . Check: host record, record type, record value, resolution platform correctness, and whether DNS has taken effect.

After successful validation, wait for the CA to complete DNS verification and issue the certificate.

Download Certificate

Once issued, the platform provides packages for Nginx, Apache, IIS, Tomcat, etc. Choose the format matching your server type — e.g., Nginx type for Nginx entry.

Filenames vary, but core files are two: certificate file and private key file . Nginx typically uses the full chain file, e.g., fullchain.pem or the platform's equivalent.

Key Protection

Private key must be protected.

Do not commit to public repos, include in article screenshots, or put in example code packages.

If private key leakage is suspected, re-issue the certificate and replace the old one.

Deploy Certificate

Place certificates on the server. The global Nginx container directory structure:

/opt/coduty/nginx/
  conf.d/
  certs/
  logs/

Organize by domain:

/opt/coduty/nginx/certs/blog.example.com/
  fullchain.pem
  privkey.pem

Create directory:

mkdir -p /opt/coduty/nginx/certs/blog.example.com

If Docker Compose mounts:

volumes:
  - ./certs:/etc/nginx/certs:ro

Then Nginx config must use container-internal paths:

/etc/nginx/certs/blog.example.com/fullchain.pem
/etc/nginx/certs/blog.example.com/privkey.pem

Remember to distinguish host vs. container mount paths. Do not write host paths into container-internal Nginx config — a common containerized Nginx mistake.

Nginx Configuration File

Config file path: /opt/coduty/nginx/conf.d/blog.aicultiv.com.conf Basic version:

server {
    listen 80;
    server_name blog.aicultiv.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name blog.aicultiv.com;

    ssl_certificate /etc/nginx/certs/blog.example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/blog.example.com/privkey.pem;

    location / {
        proxy_pass http://blog-app:8000; # note: container name
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

blog-app:8000

is an example; replace with your actual service name and port, and ensure the Nginx container can reach it via Docker network.

If no backend service exists yet, return a simple response to verify certificate and port 443:

return 200 "https is running
";

Check and Reload

After config changes, test before reloading: docker exec global-nginx nginx -t If certificate file not found, check container-internal path, mount directory, and file permissions. Enter container to confirm:

docker exec -it global-nginx sh
ls -lh /etc/nginx/certs/blog.example.com

After test passes, reload:

docker exec global-nginx nginx -s reload

Recommendation: for any number of application sites, adopt the habit of nginx -t first, then reload .

Testing

Verify port 443 accessibility. Cloud security group must allow TCP 443; host firewall must allow it too.

Using ufw:

sudo ufw allow 443/tcp
sudo ufw status verbose

Confirm host listening: sudo ss -lntp | grep ':443' Final access verification:

curl -I https://blog.aicultiv.com
curl -I http://blog.aicultiv.com

HTTPS should return 200 or application's own response.

HTTP should return 301 or 308 and redirect to HTTPS.

Browser test: if certificate error appears, check expiry, domain match, full certificate chain usage, DNS pointing to correct server .

Common Issues

Five main categories:

Certificate domain mismatch — accessing www.example.com with a cert covering only blog.example.com.

Container path confusion — Nginx config must use container-internal paths.

Only configuring 443, forgetting 80→HTTPS redirect.

Remembering renewal only when certificate is near expiry.

Private key leakage.

From work experience, probability of occurrence: #2 > #3 > #4 . #1 and #5 are less frequent.

Manual application and deployment help understand the flow, but long-term maintenance becomes tedious. For multiple subdomains or automatic renewal, wildcard certificates and auto-renewal are needed. Next article covers wildcard certificates and acme.sh for multi-domain certificate management, moving HTTPS from "configure once" to "suitable for long-term automatic maintenance."