"As a Keyfactor customer, we were able to scale up 6,000 VPN/remote access users prior to COVID-19. Keyfactor didn't miss a beat and worked flawlessly."
Large Communications Company
Amidst the coronavirus (COVID-19) outbreak, we’ve developed this resource hub to offer insights and recommendations for PKI and security professionals to quickly secure a remote workforce at scale.
Virtually meet with our resident PKI expert and CSO, Chris Hickman. Ask questions and get practical recommendations about deploying (or adapting) PKI to support your remote workforce. No sales, no marketing – just expertise.
Large Communications Company
Every year, enterprises face unforeseen events that can disrupt operations. These events are rarely predictable, and they often create significant challenges for IT and security teams, the network, even hardware supply chains. That’s where business continuity comes in – to ensure that core functions remain intact, despite the disruption. A critical component of business continuity is public key infrastructure (PKI).
If you’re standing up a new CA to expand certificate use cases (e.g. SSL VPN) or meet a rapid increase in certificate issuance, resist the temptation to cut corners during implementation. Sometimes it’s just too easy to click “next, next, next” when configuring a Microsoft CA, but simple missteps can expose your organization to serious risk and service disruptions down the line.
A Root CA is the foundation of trust for your PKI. It should be kept offline, air-gapped from the network, and protected with an HSM. However, this means that routine maintenance tasks like publishing a certificate revocation list (CRL) require multiple staff to be physically present. If remote HSM cardholders are miles (not steps) from the Root CA server, this becomes much more difficult.
There are three points in time that matter when it comes to your CRL: the time you publish it, the time it expires, and the period of overlap in between. Remember that CRL publishing is a manual process for offline CAs. The purpose of this overlap is to provide time to manually push the new CRL before the old CRL expires, and to avoid a gap in availability.
It seems simple, but we see issues here far too often. Carefully consider if there is enough disk space on all of the Issuing CA servers to handle expanded use. For example, if you enable thousands of remote workers with certificates for SSL VPN, you must ensure the CA database is equipped to store the influx of certificates and audit logs without latency issues.
Beyond the nuts and bolts of PKI, it’s critical to keep a complete inventory of every certificate issued form both your internal and public CAs. Know where every certificate lives and which applications are dependent on them. If SSL VPN becomes a business-critical application for your workforce, you’ll need to re-assess the risk related to these certificates.
A fundamental rule in PKI is that a certificate cannot have a lifespan beyond the expiration of the CA it was issued from. If your Root CA expires, all certificates issued from it expire. Industry-standard practice is to renew the Root CA after 10 years, and re-key after 20 years. If your Root CA is up for renewal in the next 8-12 months, you’ll need to start planning resources appropriately.
If a CA is down, you’ll be unable to issue new certificates, but if your CRL is expired, all of your certificates become immediately unusable. That’s because most applications need to check the validity of certificates against a CRL or OCSP server. If they cannot reach the CRL server, or if the CRL itself is expired, users will be unable to access their application.
When an application checks for revoked certificates, it retrieves the current CRL from a specified CRL distribution point (CDP). After the CRL is retrieved, it’s typically cached until it expires. If users move outside your network, the CDP must be reachable over the Internet to ensure that devices can still retrieve the new CRL when needed. The CRL should be accessible via an HTTP URL.
Many assume that, if they have a backup, they can recover their PKI. However, CA backups aren’t foolproof and they need to be regularly tested. If you have a backup of your CA database, but not the HSM, the CA can’t be recovered anyways. Ensure that everything is automatically and periodically backed up to ensure resiliency should a system failure occur.
Organizations cannot afford the application downtime or service disruptions caused by expired certificates. However, chasing down application owners to renew their certificates can be challenging if employees work remote. As you build your inventory, actively monitor certificates, define clear responsibilities, and notify owners well before expiration (90/60/30 days).