SSL Certificates

Every surge.sh subdomain is served over HTTPS automatically—nothing to do. For custom domains, the CLI gives you three commands: encrypt to provision a managed certificate, certs to inspect what's installed, and ssl to bring your own.

Provisioning a managed certificate

surge encrypt example.com

encrypt provisions a certificate for your custom domain from a trusted certificate authority and installs it across the CDN, streaming progress as it goes:

$ surge encrypt example.com

   Running as you@example.com (Standard)

     encryption: [====================] 100%

   Subject:    example.com
   Issuer:     Let's Encrypt
   Expires:    in 89 days
   Auto-Renew: yes

Certificates renew automatically—encrypt is a one-time step per domain.

Forcing HTTPS

Provisioning a certificate makes your site available over HTTPS. To also redirect all plain-HTTP traffic, publish with an explicit protocol on the domain:

surge ./dist https://example.com

The protocol is remembered as project configuration—subsequent deploys keep the behavior. (Publishing to http://example.com does the reverse and pins the project to HTTP.)

Inspecting certificates

surge certs example.com

Prints every certificate installed for the domain—subject, issuer, alternate names, expiry, and whether auto-renewal is on. To check certificate state on each individual edge node (useful when diagnosing propagation), see surge audit.

Bringing your own certificate

If you have a certificate already—an organization-validated or wildcard cert, say—upload it as a PEM bundle containing the certificate, any intermediates, and the private key:

surge ssl example.com --pem ./example.com.pem

The bundle is validated before it's applied; an invalid PEM is rejected with an explanation. Custom certificates require a paid plan.