Certificates

TLS/SSL certificates are required to serve websites and APIs over HTTPS, ensuring encrypted communication and trust for end users. Managing certificates correctly is crucial for both security and availability — expired or misconfigured certificates can take services offline.

Certificate Providers

Certificates can be issued by different providers depending on project needs:

Let’s Encrypt – free and automated certificates, widely used for most web projects. Ideal for short-lived certificates with automated renewal.
DigiCert, GlobalSign, Sectigo, etc. – commercial providers that offer Extended Validation (EV) or Organization Validation (OV) certificates, often required for enterprise or compliance reasons.
Cloudflare – provides certificates as part of their proxy/CDN services. Cloudflare manages the certificates automatically, simplifying renewal.

The choice of provider depends on budget, automation needs, and compliance requirements.

To install a SSL certificate for a specific domain name. The DNS needs to be configured to points to the correct server.

Renewal Process

Certificates must be renewed before expiration to avoid downtime.

Auto-renewal – with Let’s Encrypt or Cloudflare, renewal is automated and certificates typically renew every 60–90 days. This is preferred whenever possible.
Manual renewal – with some commercial providers (e.g. DigiCert), certificates may need to be requested, validated, and installed manually on servers. Manual processes require reminders and monitoring to avoid expiration.

Installation and Updates

How certificates are installed depends on hosting:

Local VMs / bare metal – certificates are installed in the web server configuration (e.g. NGINX, Apache, IIS). Renewal may be automated with tools like Certbot (for Let’s Encrypt) or handled manually.
Dockerized environments – certificates are often mounted as volumes into containers, or managed by reverse proxies like NGINX or Traefik that handle certificate termination.
Cloud services – platforms like Azure App Service, AWS Certificate Manager, and Cloudflare integrate certificates automatically with applications. Updates are handled by the platform when auto-renew is enabled.

Example (NGINX SSL config):

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://localhost:3000;
    }
}

Self-Signed Certificates for Local Development

A self-signed certificate is a TLS/SSL certificate that is generated locally instead of being issued by a trusted Certificate Authority (CA). It allows you to run your local application over HTTPS, but browsers and tools won’t trust it by default. This makes it useful for development but never for production.

Why Use Self-Signed Certificates Locally?

Some APIs require HTTPS origins for CORS or webhooks.
Secure cookies and authentication flows (OAuth, OpenID Connect) only work over HTTPS.
It helps mirror production behavior more closely during development.

Without HTTPS locally, certain integrations may simply not work.

Generating a Certificate

You can generate a self-signed certificate with OpenSSL:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout localhost.key -out localhost.crt \
  -days 365 -subj "/CN=localhost"

This produces localhost.key (private key) and localhost.crt (certificate).

For easier browser trust, tools like mkcert can generate certificates and install a local CA so browsers won’t show warnings:

mkcert -install
mkcert localhost

Could not fetch repo for this block.

Using Self-Signed Certificates in Local Applications

PHP (Laravel, Symfony, or other PHP apps)

With NGINX:

server {
  listen 443 ssl;
  server_name localhost;

  ssl_certificate     /path/to/localhost.crt;
  ssl_certificate_key /path/to/localhost.key;

  root /var/www/html/public;
  index index.php;

  location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  }
}

.NET provides a built-in development certificate:

dotnet dev-certs https --trust
dotnet run

Self-signed certificates can be used for all types of web projects. But built in solutions for the framework is recommanded.

Important Notes

Browsers will warn about self-signed certificates unless you explicitly trust them (using mkcert avoids this).
Self-signed certificates must never be used in production. They are only for development or testing.
Always keep your private key (.key file) secure — even in local projects.