Self-Signed vs CA-Signed

A self-signed certificate is one where the issuer and subject are the same entity — the certificate signs itself. A CA-signed certificate is issued (and signed) by a Certificate Authority that clients already trust. The distinction matters for trust, automation, and operational complexity.

Key Differences

When to Use Self-Signed

• Local development — use dotnet dev-certs https --trust or mkcert to avoid browser warnings.
• Internal services — mTLS between microservices where you control both ends and can distribute the CA certificate.
• Testing and CI — ephemeral certificates for integration test environments.
• Air-gapped networks — environments with no internet access to reach a public CA.

When to Use CA-Signed

• Public-facing websites and APIs — browsers and mobile clients need to trust you automatically.
• Third-party integrations — partners expect a publicly trusted certificate.
• Compliance requirements — PCI-DSS, SOC 2, and similar standards require CA-issued certificates.

Decision Flowchart

1. Will external clients or browsers connect? Yes→ Use a CA-signed certificate.
2. Is this for development or testing only? Yes→ Self-signed is fine.
3. Do you control all connecting clients? Yes→ Internal CA or self-signed with trust distribution.
4. Do you need automated renewal? Yes→ Consider Let's Encrypt (free, ACME-automated).
5. Is cost a constraint? Yes→ Let's Encrypt or ZeroSSL offer free DV certificates.

Internal PKI: The Middle Ground

Many organizations operate their own internal CA (using tools like Active Directory Certificate Services, step-ca, or cfssl). This gives you the automation and revocation infrastructure of a public CA while keeping full control. Clients within your network trust your root CA via Group Policy, MDM, or configuration management.