Skip to main content
banner image
venafi logo

5 Scariest Ways Your Developers Can Use Digital Certificates

5 Scariest Ways Your Developers Can Use Digital Certificates

scary devops tricks
October 26, 2017 | Scott Carter

It’s hard to argue that that all web services and applications should not be secured using HTTPS. However, securely obtaining and deploying the certificates needed for securing web services is a challenge, especially for developers.

Simply put, there is no easy way for developers to request certificates that comply with corporate policy. First, they need to know where the internal CA is, then they must be granted access to it and possess the proper credential to authenticate. Once they pass those hurdles, they need to know how to request a certificate with the proper characteristics, including who’s using it, what it will be used for and how long it should be valid. All of these delays will tempt developers to sidestep security to meet their SLAs.

Here are five DevOps shortcuts that should make the hair on the back of your neck stand on end:

  1. Not using TLS/SSL to secure connections
    When much of the DevOps process is automated, manual certificate processes will disrupt the workflow—something developers would rather avoid. In fact, many developers find it easier to ignore certificates than to allow security to delay the release. Deploying web services without securing them with HTTPS leaves end users vulnerable.
     
  2. Spinning up their own certificate authorities
    Even if they do use certificates, developers often look for shortcuts to simplify typically arduous security processes. They need look no further than to their DevOps platforms, which provide a script or instructions that allow developers to spin up their own internal certificate authority (CA). This allows developers to issue as many certificates as they need as fast as they need them. The challenge is that these “test” certificates are not always replaced by corporate-compliant certificates when the application moves to production. If that happens, your organization will be exposed to a veritable avalanche of certificates that you can’t see or that you may not even know about.
     
  3. Introducing self-signed certificates
    You should also be wary of how your in-house developers are using self-signed certificates. Rather than purchasing CA certificates, developers can download an open source implementation of SSL and TLS called OpenSSL. They can then create the certificates they need in order to develop and test software. When used in production versions of applications, these self-signed certificates can make you vulnerable to unforeseen attacks. If not properly monitored, self-signed certificates can allow cyber-criminals to conduct man-in-the-middle attacks that impersonate banking, e-commerce, and social media websites.
     
  4. Creating certificates with weak signature algorithms
    Dismissing or implementing keys and certificates poorly not only exposes your organization to unnecessary security vulnerabilities, but it can also lead to chaos by inserting inconsistent, manual steps into an increasingly automated environment. If you don’t maintain control over the security of your certificates, you may inadvertently enable attackers to use a compromised, stolen, or forged certificate to impersonate, eavesdrop, and monitor your infrastructure and decrypt communications you thought were private.
     
  5. Sidestepping or completely ignoring security policies
    Finally, developers are typically not security experts and most do not aim to be. They are less likely to consider anything but the most basic security measures to meet their objectives, especially given past struggles with the error-prone manual nature of certificate provisioning. The result is that security policies are either ignored completely or minimized to maintain the velocity of DevOps. This oversight can create blind spots in your security posture that allow cyber criminals to hide in your encrypted tunnels.

The speed of DevOps does not have to come at the expense of security. There are ways that you can centralize, standardize, and automate the process of procuring keys and certificates as part of your end-to-end DevOps environment. Automating certificate acquisition will enable your DevOps teams to deliver applications and IT services more effectively and more securely. But to do this, your DevOps practitioners need to understand that they share important responsibilities for security; it isn’t just someone else’s job.

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

Déjà Vu at LinkedIn: Second TLS Certificate Expiry in 2 Years

Déjà Vu at LinkedIn: Second TLS Certificate Expiry in 2 Years

Prepare this presentation and send it to me, once approved you can teach entire team.

Overheard at Machine Identity Protection Global Summit 2019

machine identity protection

Leaders Underscore the Critical Nature of Machine Identity Protection at Inaugural Global Summit

About the author

Scott Carter
Scott Carter

Scott Carter writes for Venafi's blog and is an expert in machine identity protection.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat