As organizations scale their Kubernetes infrastructure, managing SSL certificates becomes increasingly complex. Let’s dive into some common misconceptions and explore how certificate management really works, especially when dealing with custom Certificate Authorities (CAs).

The Common Misconception

Many developers initially believe that having an SSL certificate for a domain (let’s say example.com) allows them to create new certificates for its subdomains. This seems logical but isn’t how SSL certificates actually work.

Understanding Certificate Types

Standard SSL Certificates

A standard SSL certificate from a provider like Verisign is an end-entity certificate. Think of it as a leaf node in a tree - it can prove its own identity but can’t vouch for others. This means:

  • It works for the specific domain it was issued for
  • It might cover www.example.com if included
  • It cannot create or sign other certificates

Wildcard Certificates

Wildcard certificates (*.example.com) are more flexible but still have limitations:

  • Cover all first-level subdomains
  • Don’t cover the root domain or multi-level subdomains
  • Cannot create new certificates
  • Share the same private key across all subdomains

The Custom CA Approach

This is where things get interesting. Organizations sometimes opt for a custom Root CA, which provides maximum flexibility but comes with its own challenges.

How It Works

  1. Create or obtain a Root CA certificate and private key
  2. Configure cert-manager to use this CA for signing certificates
  3. Install the Root CA certificate in user browsers
  4. Deploy services with automatically generated certificates

Advantages

  • Complete control over certificate issuance
  • Automated certificate management with cert-manager
  • No external CA dependencies
  • Cost-effective for large deployments

Challenges

  • Requires careful private key management
  • Must distribute and maintain Root CA trust in browsers
  • Not practical for public-facing websites
  • Increased security responsibility

Implementation in Kubernetes

Here’s where tools like cert-manager shine. With a custom Root CA, you can:

  • Automatically generate certificates for new services
  • Handle certificate rotation
  • Manage different certificate types for different environments
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: store-example-com
spec:
  secretName: store-tls
  issuerRef:
    name: custom-ca-issuer
    kind: ClusterIssuer
  dnsNames:
  - store.example.com

Best Practices and Considerations

  1. Security First

    • Store the Root CA private key securely
    • Use separate CAs for different environments
    • Implement proper access controls

  2. Automation

    • Use cert-manager for certificate lifecycle management
    • Automate CA trust distribution
    • Monitor certificate expiration

  3. Environment-Specific Approaches

    • Development: Custom CA is perfect
    • Internal tools: Custom CA works well
    • Public websites: Stick to public CAs

When to Use What

Use Public CAs When:

  • Building public-facing websites
  • Can’t control client environments
  • Need universal trust

Use Custom CA When:

  • Operating in controlled environments
  • Managing many internal services
  • Need complete control over certificate lifecycle
  • Have proper security measures in place

Conclusion

While custom Root CAs provide powerful capabilities for certificate management in Kubernetes, they’re not a silver bullet. The choice between public CAs and custom CAs should be based on your specific use case, security requirements, and operational capabilities.

Remember: The power to create certificates for any domain comes with great responsibility. Ensure your team is prepared for the security implications before implementing a custom CA solution.