Self-Signed Certificates Explained

A self-signed certificate is a digital certificate that is signed by the same private key associated with the certificate rather than by a separate trusted Certificate Authority. Self-signed certificates can provide encryption for TLS connections, but they do not automatically establish trusted identity for clients such as web browsers.

Self-signed certificates are useful in development environments, private networks, testing systems and internal applications where an organization controls the clients that connect to the service. They are generally not suitable for public websites when users need a seamless HTTPS experience without certificate warnings.

What Is a Self-Signed Certificate?

A certificate normally contains a public key, identity information, validity dates, extensions and a digital signature from an issuer. With a self-signed certificate, the certificate's issuer is effectively the same entity represented by the certificate, and its signature is created using the corresponding private key.

Self-Signed Certificate

Certificate
    │
    ├── Public key
    ├── Subject
    ├── Validity period
    ├── SAN
    └── Signature
          ↑
          │
Same certificate's private key

The signature can be cryptographically verified using the public key contained in the certificate. However, successful signature verification does not mean that a browser should automatically trust the certificate. Cryptographic validity and trust are separate concepts.

How Self-Signed Certificates Work

When generating a self-signed certificate, a private key is first created. The corresponding public key is included in the certificate along with information describing the identity of the service. The certificate is then signed using the private key.

Generate private key
        ↓
Create certificate information
        ↓
Include public key
        ↓
Sign certificate with private key
        ↓
Self-signed certificate

A TLS server can use the resulting certificate and private key to establish an encrypted connection. The encryption part of TLS can therefore work even when the certificate is not trusted by the client.

Self-Signed vs CA-Signed Certificates

Encryption vs Trust

One of the most important concepts when working with self-signed certificates is the difference between encryption and authentication. A self-signed certificate can be used to establish encrypted TLS communication, but the client has no independent reason to trust that the certificate belongs to the expected server.

A certificate can provide cryptographic protection without being trusted by default.

For example, a developer can create a self-signed certificate for an internal server and configure HTTPS successfully. The connection can be encrypted, but a browser may display a warning because it cannot establish a trusted certification path.

Why Browsers Warn About Self-Signed Certificates

Browsers rely on trusted root Certificate Authorities to determine whether a website certificate belongs to an issuer recognized by the browser or operating system. A self-signed certificate normally does not chain to one of those trusted roots.

Website certificate
       ↓
Self-signed
       ↓
Not issued by a trusted public CA
       ↓
Browser cannot establish normal trust
       ↓
Certificate warning

The warning does not necessarily mean that the certificate is malformed or that TLS encryption is impossible. It means the browser cannot establish the required trust relationship automatically.

What Does a Certificate Warning Mean?

A certificate warning tells the user that the browser could not validate the certificate according to its trust rules. Depending on the browser and configuration, the warning can mention an untrusted issuer, invalid certificate authority, hostname problem or another certificate validation issue.

When Self-Signed Certificates Are Useful

Self-signed certificates are particularly useful when the environment is controlled by the developer or organization and automatic public trust is not required.

• Local development environments.
• Testing HTTPS configurations.
• Development servers.
• Private networks.
• Internal applications.
• Temporary staging systems.
• Laboratory and experimental environments.
• Testing certificate-related software.

Self-Signed Certificates for Local Development

Developers often need HTTPS locally to reproduce production behavior, test secure cookies, verify service workers, test OAuth callbacks or work with APIs that require secure origins. A self-signed certificate can provide a simple way to enable TLS during development.

However, manually accepting a browser warning every time is inconvenient. For a better local development experience, developers can create a local development Certificate Authority and install its root certificate into the development machine's trust store.

Self-Signed Certificate vs Local CA

A single self-signed certificate and a private local CA solve related but different problems. With a self-signed server certificate, the server certificate itself must be explicitly trusted. With a local CA, the developer trusts the CA once and can then issue separate server certificates that chain to that trusted CA.

Option 1:

Self-Signed Server Certificate
        ↓
Trust server certificate directly


Option 2:

Local Root CA
     ↓
Server Certificate
     ↓
Trust the Root CA

Self-Signed Certificates in Private Networks

Organizations may use certificates that are not publicly trusted for internal services. However, instead of creating independent self-signed certificates for every server, larger environments generally benefit from a private PKI with a controlled root CA and intermediate CAs.

Private Root CA
      ↓
Intermediate CA
      ↓
Internal API
Internal Dashboard
Internal Git Server
Internal Monitoring

The organization can install the private root CA into managed client devices. Once the root is trusted, certificates issued by the organization's CA can be validated without requiring a public Certificate Authority.

Self-Signed Certificates and Certificate Chains

A typical self-signed certificate does not have a traditional chain ending at a separate trusted root CA. The certificate itself acts as the trust endpoint, but the client must explicitly trust it if the connection is to be accepted without warnings.

Traditional public certificate:

Server Certificate
      ↓
Intermediate CA
      ↓
Trusted Root CA


Self-signed certificate:

Server Certificate
      ↓
Self-signed
      ↓
Must be explicitly trusted

This is one reason self-signed certificates are fundamentally different from certificates issued through a public PKI. The trust decision must be made directly by the client or by an administrator controlling the environment.

Creating a Self-Signed Certificate with OpenSSL

OpenSSL can generate a private key and self-signed certificate from the command line. A basic example is useful for development and testing environments.

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout server.key \
  -out server.crt \
  -days 365

This command generates a private key and creates an X.509 certificate signed using that key. The -days option controls the certificate validity period in this example.

Including Subject Alternative Names

Modern TLS clients use the Subject Alternative Name extension to determine which hostnames and other identities a certificate covers. A development certificate should therefore include the names that the client will actually use.

Subject Alternative Name:

DNS:localhost
DNS:dev.example.test
IP:127.0.0.1

If a certificate does not contain the hostname or IP address being accessed, the client can reject it even if the certificate is otherwise trusted. Trust and hostname validation are separate checks.

Self-Signed Certificate File Formats

Self-signed certificates can be stored in the same certificate formats used by CA-issued certificates. PEM is especially common because it represents certificates and keys as Base64-encoded blocks surrounded by BEGIN and END markers.

-----BEGIN CERTIFICATE-----
Base64 encoded certificate data
-----END CERTIFICATE-----

The private key is stored separately and should be protected carefully. A certificate contains public information, while the private key must remain secret.

Certificate and Private Key

Security Risks of Self-Signed Certificates

The primary security problem with an untrusted self-signed certificate is not that its cryptography necessarily fails. The problem is that the client has no trusted external authority confirming that the public key belongs to the expected server.

If users are trained to bypass certificate warnings, they may become less likely to notice a genuine man-in-the-middle attack or another certificate configuration problem.

• No automatic public trust.
• Users may ignore certificate warnings.
• Identity is not independently validated by a public CA.
• Manual trust distribution can be difficult at scale.
• Incorrect deployment can create confusing TLS errors.
• Certificate management becomes the organization's responsibility.

Can Self-Signed Certificates Be Secure?

Yes, self-signed certificates can be used securely when the trust model is deliberately controlled. For example, an administrator can install a known certificate or private CA root on managed devices and verify that the certificate was created by the expected administrator.

The important distinction is between an untrusted certificate that users are told to accept and a certificate that is explicitly trusted through a controlled process. The latter can be appropriate for private infrastructure.

When Not to Use a Self-Signed Certificate

Self-signed certificates are generally a poor choice for public websites, public APIs and services accessed by users whose devices you do not control. Public services should normally use certificates issued by a publicly trusted Certificate Authority.

• Public production websites.
• Customer-facing APIs.
• E-commerce platforms.
• Public authentication services.
• Public SaaS applications.
• Internet-facing services where users cannot be centrally managed.

Self-Signed Certificates for APIs

Internal APIs can use self-signed certificates when clients are configured to trust them. Public APIs should normally use publicly trusted certificates so standard HTTP clients, browsers and operating systems can validate the server without custom trust configuration.

For automated clients, administrators can explicitly configure a trusted CA bundle or certificate when appropriate. Disabling TLS certificate verification entirely is a different and much less desirable approach.

Self-Signed Certificates and Mobile Applications

Mobile applications can use private or self-signed certificate configurations when the application and its backend are controlled by the same organization. However, certificate trust must be intentionally configured and maintained across application versions and devices.

For general public applications, relying on publicly trusted certificates is usually simpler because the operating system already knows how to validate the standard public PKI hierarchy.

Self-Signed Certificates and Docker

Self-signed certificates are frequently used in local Docker environments where multiple containers communicate over HTTPS. The certificate or local CA can be distributed to the containers and host systems that need to trust the service.

Host
  │
  ├── Browser
  │
  └── Docker containers
          │
          ▼
      HTTPS service
          │
          ▼
    Local certificate

When containers need to trust a private certificate authority, the CA certificate must be installed into the appropriate trust store inside each relevant container. Installing a certificate on the host does not automatically make every container trust it.

Checking a Self-Signed Certificate

Certificate inspection tools can reveal the subject, issuer, validity period, public key information, extensions and signature details. For a self-signed certificate, the subject and issuer commonly refer to the same certificate authority identity.

openssl x509 -in server.crt -text -noout

The output can be used to verify that the certificate contains the expected SAN entries, validity dates, key information and issuer details.

Checking Whether a Certificate Is Self-Signed

One useful indicator is that the certificate's issuer and subject are the same. This is common for self-signed certificates, although determining whether a certificate is actually self-signed should also involve verifying its signature using its own public key.

Subject: CN=Internal Test Server
Issuer:  CN=Internal Test Server

Matching subject and issuer fields alone are not sufficient proof of trust or security. They only describe the certificate's identity and issuer relationship.

Self-Signed Certificate Expiration

Self-signed certificates have validity periods just like CA-issued certificates. A client can reject a certificate that is expired or not yet valid even if the certificate has been explicitly trusted.

Self-Signed Certificate Renewal

Renewing a self-signed certificate usually involves generating a new certificate with an updated validity period and deploying it to the relevant service. If clients explicitly trust the old certificate rather than a stable private CA, renewal may also require updating those clients.

Using a private CA for larger internal environments can simplify certificate management because clients can trust the CA root while individual server certificates are renewed or replaced underneath it.

Self-Signed Certificate vs Private CA

For one temporary development server, a self-signed certificate can be perfectly adequate. For dozens or hundreds of internal services, a private PKI usually provides a more scalable approach to issuing, renewing and revoking certificates.

Public CA Alternatives

For public websites, a certificate issued by a publicly trusted Certificate Authority is normally the preferred solution. Public CA certificates can be validated by standard browsers and operating systems without requiring users to install a custom root certificate.

Common Mistakes

• Using a self-signed certificate on a public production website.
• Telling users to permanently ignore browser certificate warnings.
• Disabling TLS certificate verification to make an application work.
• Forgetting to include the required hostname in the SAN extension.
• Exposing or committing the private key.
• Using very long-lived certificates without tracking them.
• Using independent self-signed certificates for a large internal infrastructure.
• Assuming encryption automatically means identity is trusted.
• Forgetting to install the required private CA certificate on client devices.
• Failing to monitor certificate expiration dates.

Best Practices

• Use self-signed certificates primarily for controlled development, testing and private environments.
• Include correct Subject Alternative Name entries.
• Protect private keys with appropriate permissions.
• Track certificate expiration dates.
• Use a private CA when many internal services need certificates.
• Install private CA roots only on devices that should trust the internal infrastructure.
• Never disable certificate verification as a permanent production solution.
• Use publicly trusted certificates for public-facing services.
• Document which systems trust internal certificates.
• Test certificate renewal before certificates expire.

Frequently Asked Questions

Helpful Certificate Tools

A CSR Generator helps create Certificate Signing Requests for certificates issued by a CA, a PEM Certificate Viewer displays detailed information from PEM-encoded certificates, a Certificate Chain Viewer helps inspect certificate relationships, a TLS Version Checker checks supported TLS protocol versions, and a Certificate Expiration Checker helps identify certificates that are approaching their expiration date.

Conclusion

Self-signed certificates are certificates signed by their own associated private key rather than by an external Certificate Authority. They can provide TLS encryption and are useful for development, testing and controlled private environments, but they do not automatically provide the trusted identity that browsers expect from public websites.

The key distinction is between encryption and trust. A self-signed certificate can encrypt traffic, but clients must explicitly trust it before they can treat the certificate as an authenticated identity. For small development environments, self-signed certificates can be convenient. For larger internal infrastructures, a private CA is usually easier to manage, while public websites should generally use certificates issued by a publicly trusted Certificate Authority.