GlobalSign Blog

DevOps Pipeline Security: Avoiding the Risks of Self-signed Certificates

DevOps Pipeline Security: Avoiding the Risks of Self-signed Certificates

SSL/TLS protocols are a business imperative for securing connections between apps, devices, and machines accessible over the Internet. These protocols require certificates to secure data through encryption and authentication to mitigate potential tampering and malicious exploits. The most secure certificates are issued and validated by trusted Certificate Authorities (CAs), ensuring a crucial trust chain for authentication. 
In this blog we look at the risk of self-signed certificates and why you shouldn’t use them to secure your DevOps pipeline.

What are Self-signed Certificates?

  • Publicly-trusted certificates, used for public-facing web servers and applications, must be issued by an external, trusted third-party CA that securely verifies the domain owner. Some organizations run their own internal PKI and issue their own privately-trusted SSL/TLS certificates for their internal networks to authenticate devices and users.
  • Self-signed certificates are not signed by either a public or private certificate authority, because the information within self-signed certificates has not been verified and authenticated by a trusted Certificate Authority, they can trigger security alerts. This poses a significant problem when web browsers and operating systems flag certificates not signed by a publicly trusted CA due to security risks to users. Without authentication via a CA, users cannot determine if the certificate is trustworthy or generated by malicious actors.

Why are Self-signed Certificates an Attractive Option for Developers?

Self-signed certificates are used by developers in low-risk internal networks and software development and testing phases.

  • Self-signed certificates offer expediency and agility in all phases of the development cycle
  • Generating self-signed certificates eliminates lengthy waiting periods for verification and signing processes that cause time loss, frustration, and disruption
  • Self-signed certificates are not subject to regulations regarding validity periods. In contrast, publicly trusted SSL/TLS certificates are currently limited to a validity period of 13 months

If developers use self-signed certificates, strong policies for protection and access security should be in place. An established team in charge of certificate management with efficient monitoring tools is essential to keep track of all certificates and their authenticity. Unfortunately, the security issues involved are not always top of mind. In the same way that shadow IT causes complexity and unnecessary risk, self-signed certificates can lead to significant risk factors.

Why Developers Should Resist Using Self-signed Certificates

The most significant argument in opposition to self-signed certificates is simply that they are not trusted. Outside of internal networks, SSL/TLS certificates need to be signed by a trusted CA to gain that important level of user trust. Validation by a trusted public CA is crucial to eliminate the danger of untrackable rogue certificates, spoofing, and delivery of malicious code.

Risk Factors Surrounding the Use of Self-signed Certificates

  1. No revocation process – There is no reporting authority for revoking expired or compromised certificates, which leaves potential gateways for malicious exploitation and breaches.
  2. Lack of visibility, inventory knowledge, and control – It is difficult for security teams to know how many certificates, installation location, ownership, and private key storage details or when a certificate is compromised.
  3. Lack of technical support – Certificates generated in-house are lacking in the breadth of expertise, management tools, and revocation mechanisms provided by public certificate authorities.
  4. Poor compliance and alignment with security standards – There is often a deficient knowledge of regulations and application of best practices to meet compliance standards.

Why Hosted PKI in DevOps is a Secure and Advantageous Alternative

Public Key Infrastructure, or PKI, is the technology ecosystem of policies, procedures, hardware, and software that enables the issuance, management, storage, and revocation processes for digital certificates. PKI allows the creation of digital certificates that authenticate the identity of devices, users, and services using data encryption, digital signatures, and certificate authentication issuance through trusted certificate authorities. 
For developers, PKI-as-a-Service (PKIaaS) is a great alternative to self-signed certificates for ease of use, scalability, efficiency, and trust.

Benefits of Hosted PKI for DevOps

A hosted PKIaaS provides numerous advantages, including:

  • Full visibility, management control, and knowledge of every certificate issued
  • Eliminates vulnerability risks from untrusted, untrackable rogue certificates and certificate spoofing
  • Faster certificate issuance
  • Enables more secure DevSecOps automation
  • Lowers cost of SSL/TLS ownership
  • Automates certificate deployment
  • Includes a publicly trusted root compatible on all operating systems and browsers
  • Provides freedom from in-house certificate management
  • Saves time and cost managing software, maintenance, employee training, monitoring, and health checks

GlobalSign’s PKI Service for DevOps Can Help Overcome the Certificate Challenges

GlobalSign can overcome DevOps certificate challenges with our hosted, reliable, and trusted CA services. Partnering with GlobalSign means developers have a single source to turn to for all certificate needs, leaving them free to focus on core competencies. Our PKI expertise ensures best practices and audit requirements are met while delivering world-class support and Service Level Agreements (SLA).

GlobalSign’s PKI certificate services are delivered at cost-effective DevOps speed while ensuring certificates and PKI components are up to date with best practices and regulations.

GlobalSign Hosted PKI Features

  • Hosted RFC 5280-compliant revocation services (CRL or OCSP), secure offline key storage, and hosting and management of dedicated or shared, public or private customer roots
  • Delivered via GlobalSign's API’s or ACME integration
  • Direct integration with Venafi as a Service and HashiCorp Vault available
  • Kubernetes Certmanager plugs in via Atlas
  • CLI tool for certificate issuance, renewal and revocation with HVClient
  • Covers certificate needs across the entire application stack

Learn more about GlobalSign’s hosted PKI services for DevOps

Share this Post

Recent Blogs