Certificate Revocation – Challenges and Best Practices

Revoking a certificate invalidates a certificate before its scheduled expiration date. There are many reasons to revoke a certificate including, but not limited to, compromise or loss of the corresponding private key, key is no longer needed, and more. While revocation is typically discussed in the context of X.509 certificates, other certificate types such as secure shell (SSH) and pretty good privacy (PGP) (yes, we are referring to PGP public keys as certificates) also support revocation. Despite the concept of revocation having broad support, in the following paragraphs we will show how the implementations are more complicated with a lot of edge cases and overall poor support.

Methods of Certificate Revocation

The most common way to revoke a certificate is by publishing a list of revoked certificates that clients can consume. In the X.509 world this is done via a Certificate Revocation List (CRL). In this case, the Certificate Authority (CA) publishes the CRL that contains the list of certificates, the revocation state (i.e., Revoked or Hold), the reason for revocation (i.e., unspecified, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, privilegeWithdrawn, or aACompromise), and when the revocation took place (note: per RFC 5280 there is a difference between the Revocation Date and the Invalidity Date but Ballot CSC-12 of the CA/Browser Forum simplified this in 2021).

While CRLs work in theory, they have many problems in practice. In order for the CRL to be accessed it must be available to the client in real-time and must therefore be accessible “online”. While this isn’t usually a problem when navigating websites on the public web, it can be a problem on private networks and non transport layer security (TLS) use cases (e.g., validating signatures on code or documents on an offline machine). Additionally, if the CA is popular it may have issued a lot of certificates which can result in large CRLs which consume lots of bandwidth, negatively impact performance, and open up the possibilities of denial of service (DoS) attacks. To combat this CAs only periodically publish new CRLs and clients cache CRL results which leads to another problem – staleness of CRLs. If a certificate has been revoked it can sometimes take up to 24 hours before a client sees the updated status and by then it may be too late.

To overcome these issues, the Online Certificate Status Protocol (OCSP) was designed. OCSP allows clients to query the status of a single certificate in real-time, thereby significantly reducing the size of the data transferred and improving performance and DoS-mitigation. However, since the client queries a specific certificate at the moment it is being consumed, it leaks information to the CA about what service the client is consuming and therefore has privacy concerns. OCSP can also put a lot of burden on CAs, especially for certificates that are consumed often by many different clients (e.g., for popular websites). Protocols like OCSP with stapling have been designed to overcome this issue but never gained widespread adoption.

Fail Open vs Fail Closed

Due to the reliance on the CA infrastructure to check the revocation status, clients must decide what to do if the revocation status cannot be checked. Should the client fail open (i.e., proceed with operation such as accessing the website) or it should fail closed (i.e., don’t proceed with the operation which could mean not accessing a website or installing software)? Failing closed ties system availability to the availability of the CA infrastructure. Failing open leaves the door open for attackers to DoS the CA infrastructure so that clients don’t see that a compromised certificate was marked as revoked. Some browsers choose to fail open while some have opted to not even check the revocation status and instead rely on short-lived certificates.

Impact of a Revoked Certificate

If the client can detect that the certificate is revoked, what should it do? Some use cases are fairly obvious. For example, in a TLS case where a client is querying certificate status in real-time, a revoked certificate means that the endpoint (e.g., the server you are trying to access) should not be trusted and the TLS handshake should terminate. But what about other use cases where something was signed in the past, before the certificate was revoked? For example, software that was legitimately code signed in the past prior to its private key being compromised and certificate being revoked? Should it still pass validation? Well, if the client can verify that the signature was produced before the key compromise then yes, it should pass validation. This is why cryptographic timestamping is so important – it allows the client to reliably verify when something was produced so it can compare that against revocation and expiration dates. Note: technically cryptographic timestamping allows a client to verify that something was produced on or before a given date, not the date that the data was necessarily produced, but that distinction is beyond the scope of this post.

Best Practices

Given the complexities of revocation, the mixed support for it by common clients, and the ramifications of improper usage, what should an enterprise do? Two best practices to follow are:

1. Use cryptographic timestamping

2. Use short-lived certificates

Number 1 is pretty simple to use – just specify a publicly trusted timestamping service when signing data. Some tools automatically do this for you and others require you to do it yourself. Number 2 requires automated certificate lifecycle management (CLM) because without it certificates may expire resulting in costly outages. CLM has traditionally been very expensive but that is no longer the case. E-semnatura provides unlimited certificate lifecycle management that will not break the bank. Get in contact with us today to learn more.

Does this sound familiar? You are working at a company on a big project and are just about ready to move to production but need to add the final touches. You are told that you need TLS certificates for your load balancers, application servers, and database servers, a secure place to bootstrap some secrets from, and to turn on database encryption. Seems simple enough, you just need to find out who to request this from. You couldn’t have been more wrong – you are suddenly inundated with questions and a maze of a decision tree:

• Will the service only be used internally or will external customers have access? If internal only, the ADCS team will issue the certificates, otherwise the team that maintains the relationship with the publicly trusted certificate authority will do it.
• How will you renew the certificates? Automatically via ACME or SCEP, some server-side orchestration mechanism, manually by setting your own calendar reminder, or just hope you move on to a new job before that happens?
• Will the infrastructure sit on-premise or in the cloud? If it is in the cloud, the cloud infrastructure team will generate the keys for you, otherwise you may generate them yourself.
• What kind of keys do you plan on using? A bunch of foreign acronyms are thrown your way – ECC, RSA, PQC, etc.
• How often do your secrets need to be rotated? Will this happen automatically or manually?
• Etc.

As it will turn out, it will take almost as long to get the final touches added as it did to complete the bulk of the project thus far.

If this sounds familiar, don’t worry, you are not alone. It is no secret that tech moves quickly but oftentimes our infrastructure and processes lag behind. We are now seeing the industry catch up by deploying Enterprise Cryptographic Services. At a high level, the Enterprise Cryptographic Services team is responsible for the secure management and usage of keys, certificates, and secrets. Since these cryptographic primitives are used throughout so many of the commonly used use cases and protocols, the Enterprise Cryptographic Services team plays a crucial role in the overall enterprise security strategy.

Cryptographic Services Examples

Some examples of what the Enterprise Cryptographic Services team is responsible for include:

1. Secure key generation and storage
2. Management of the cryptographic devices that store the keys, whether on-premise, in the cloud, or both
3. Automated and manual certificate issuance and renewal
4. Proper key destruction and certificate revocation when necessary
5. Automated and manual secrets creation, rotation, and destruction
6. Auditing of permissions to keys and, ideally, real-time key usage to ensure compliance with corporate policies

Proper Tooling

To properly run an Enterprise Cryptographic Services team, the proper infrastructure and tooling is required. At a minimum, this tooling should provide:

• Native client integrations to operating systems and runtime environments via cryptographic service providers
• Integration with federated identity providers such as Entra ID, Okta, Active Directory, etc. via industry-standard protocols like OIDC/OAuth2, SAML, Kerberos, LDAP, etc.
• Support for many use cases such as TLS, Code Signing, SSH, RDP, Data Encryption, and more
• Centralized auditing over all administrative and end user requests
• Integration with private and publicly trusted certificate authorities for certificate management
• Advanced security controls such as MFA, approval workflows, just-in-time access, and others during authentication and sensitive operations
• Policy-driven key and certificate management on a per object basis
• Support classical and post-quantum cryptography
• High performance via techniques such as client-side hashing and enveloped encryption

Whether you are just starting your journey to Enterprise Cryptographic Services, have a mature service already deployed, or are somewhere in between, Ghesar is here to help. We have a wealth of experience creating, deploying, and managing Enterprise Cryptographic Services solutions, including our best in class solution Ghesar, for large and medium sized enterprises. Please contact us to us to discuss your needs.

Learn how a client-side hash signing architecture can accelerate digital signatures in your IT environment.

Ensuring the security and performance of digital signatures is a top priority for every InfoSec and DevSecOps leader. With many businesses shifting to a remote work environment due to the ongoing global pandemic, this task is made considerably more difficult.

How do you ensure the security of all digital signatures throughout a fully remote workforce, without compromising on performance?

Digital Signatures For Distributed Teams

As many companies enact work-from-home policies to keep team members safe in the midst of the COVID-19 pandemic, achieving both ironclad security and top-notch performance of digital signatures for a geographically-distributed team is now critical to business operations.

When it comes to enabling digital signatures for a distributed team, there are three general approaches:

1. Keep the private keys in software and distribute to team members as needed.
2. Place the keys in hardware protection (i.e. a hardware security module) and distribute many HSMs out to the various teams of your business.
3. Store the keys in a centrally-managed HSM and give proxied access to all end users.

Option 1 presents major security risks and shouldn’t be considered by any company that values its data security. When signing keys are stored in software, the level of protection around them is simply too weak for comfort. Attackers could gain access to the keys by compromising an employee’s device or extracting the keys from the software itself.

Option 2 offers improved security compared to the first approach, but it comes with a daunting price tag. Hardware security modules are costly so purchasing multiple HSMs is not the most cost-effective approach to enabling secure digital signatures for a large team. Moreover, keeping multiple hardware devices synchronized and performing key management across several HSMs is a very challenging task.

Option 3 is the optimal solution, if it can be done while maintaining excellent performance. This is where hash signing comes into play.

What Is Hash Signing?

The term “hash signing” can be confusing because virtually all digital signature schemes make use of some form of cryptographic hash function.

In general, a digital signature is produced by hashing the document or code that needs to be signed, then applying the cryptographic private key operation on the resulting hash value. Since cryptographic hash functions deterministically produce a small, fixed-length output from a data input of arbitrary size, the hash serves as an electronic fingerprint of the data. The hash of the data is one component of that data’s digital signature, enabling verifiers to easily detect if any changes have been made to the document or code after the signature is completed.

Note that the private key is not needed in the digital signature process until after the data is hashed. As such, it isn’t necessary to send all data to a signing server in order to create a digital signature. Instead, hashing can be performed locally, with only the hash value being sent to the signing server to complete the digital signature with the private key operation.

This client-side hashing method, known as hash signing, greatly improves the performance of remotely-generated digital signatures.

Without hash signing, companies opting for Option 3— that is, storing all private key material in centrally-managed HSMs— must upload all of the data being signed to the central signing service, then download the entire signed package once the signature is complete. For any use case that requires creating signatures for large files (e.g., code signing, document signing, cryptographic time-stamping of backups, etc.) this means it’s necessary to transport large volumes of data over the network twice, resulting in slow signature generation and unnecessary bandwidth consumption.

With hash signing properly implemented, this issue is resolved. Since only the hash of the data being signed is sent over the network to the signing server, bandwidth transmissions are kept to a minimum and the digital signature process is accelerated.

Challenges with Hash Signing

While hash signing offers significant advantages in terms of digital signature performance, it also comes with a few challenges. In particular, there are two major challenges with hash-based signing: client integrations and security.

Client Integrations

Many signing tools today assume that the signing key resides on the local computer the tool is being executed on. Similarly, hardware security module (HSM) APIs default to assuming the data that needs to be signed resides on the machine that is directly connected to the HSM. Of course, the former scenario presents major security risks, while the latter is not the case with hash signing.

Deploying a client-side hash signing architecture with existing tools, all while keeping the signing keys securely locked away in an enterprise HSM or key manager, is an extremely complex task. It requires a lot of low-level development work from cryptography experts that transparently do all the heavy lifting for you.

Fortunately, that is exactly what the team at Ghesar loves to do. We designed our flagship product, E-semnatura , to come with these cryptographic providers ready to use out of the box on all major platforms including Apple, Microsoft, Java, Android, GPG, RPM, Linux, OpenSSL, and more. Whether you are signing code, documents, challenge-response handshakes, or any other type of data, E-semnatura’s client integrations make this a seamless experience for your end users.

Security

With hash signing, the signing server only sees the hash of the data, not the entirety of the data being signed. As a result, the signing server cannot analyze that data very easily. To overcome this, Ghesar has built several crucial features into the E-semnatura Sign platform, including:

• Strong authentication and authorization
• Approval process flows for high valued keys
• Code analysis via the source code repository for code signing
• And much more.

Ready to learn more about how E-semnatura can improve the security and performance of digital signatures in your environment? Get in touch with the Ghesar team. Although the E-semnatura product is fully customer-managed, the Ghesar team will be happy to host your proof of concept free of charge so you can experience the speed and seamless integrations of E-semnatura for yourself.

In a time when digital transformation has become a foundational pillar of business success, the silent cornerstone enabling trust, security, and resilience is cryptography. Every enterprise, whether knowingly or not, is deeply dependent on cryptographic services—yet few have a handle on the scope, sprawl, or strategic importance of these services.

This reality is why I joined Ghesar as CEO. Ghesar delivers innovative cryptographic services and automation solutions that sit at the very core of enterprise security. As cyber threats scale, quantum computing looms, and AI systems demand new protections, Ghesar’s solutions aren’t just important—they’re essential to safeguarding the very infrastructure of modern business and society.

The Hidden Kernel of Cybersecurity

Cryptography powers nearly every critical function in cybersecurity:

• Authentication – Validating identities across systems, users, and machines
• Data Protection & Privacy – Ensuring confidentiality and integrity in transit, at rest, and in use
• Secure Communications – Encrypting sensitive interactions internally and externally
• Access Control – Enabling role-based privilege and authorization models
• Software Supply Chain Security – Verifying code, signatures, and sources
• IoT, Robotics, and Autonomous Systems – Securing the physical-digital interface

It is, quite literally, the underlying kernel that supports every major cybersecurity function—PKI, CLM, IAM, PAM, DLP, etc.— the cryptographic services that power these systems remain unmanaged, duplicated, and dangerously fragmented.

Unmanaged Cryptographic Sprawl

Most organizations do not realize that cryptographic assets—keys, certificates, protocols, algorithms, and signing services—are spreading like wildfire across their environments:

• From cloud computing environments / SaaS operations to on-prem IT environments
• From network devices and systems, application/web servers, middleware devices and databases
• From software supply chain and code signing to DevOps, software entities, workloads, containers, and APIs
• From human and machine identities to software entities
• Across OT, IoT, robotics, autonomous systems, and edge devices

These assets are embedded in countless IT resources, software entities tools and systems—each one implementing its own isolated cryptographic instance. This stovepiped sprawl results in:

• Operational risk and Complexity: Misconfigured crypto systems, loss of cryptographic keys, expired certificates, slow processes / crypto latency – all can bring down systems or applications, halting business operations.
• Security risk: Poorly managed cryptographic keys or misconfigured implementations, vulnerable algorithms or key lengths – all become easy attack vectors for attackers, ransomware, insider threats, or nation-state actors.
• Compliance risk: Regulatory mandates and changing industry standards (NIST, PCI-DSS, US EO 14028, GDPR, NIS2) increasingly require centralized visibility and control over cryptographic functions.

Worse still, most organizations cannot even see where their cryptographic services live, let alone control them.

The Need for Unified Enterprise Control

We need to start thinking about cryptographic services the same way we think about other core enterprise functions. Just as identity and access management (IAM) or endpoint security require central governance, cryptographic services need:

• Enterprise administration and control
• Permissions derived from federated identity providers
• Automated key and certificate lifecycle management
• Visibility across cloud, on-prem, and hybrid environments
• Ease of use via no-code and low-code integrations
• Readiness for quantum-safe algorithms

Enterprises must move from ad hoc usage of cryptography to a strategic cryptographic mission—where crypto services are unified, governed, automated, and integrated across the business.

Why Ghesar

Ghesar was founded to solve this exact problem. Its unique approach to cryptographic services builds upon the identity-centric and zero-trust-focused foundations laid by modern cybersecurity initiatives. By enforcing security controls at the cryptographic primitive level, Ghesaris able to draw the smallest zero-trust boundary possible – at the datum level, which is akin to the cellular level of an enterprise’s IT infrastructure. This approach enables a healthy balance of Security, Performance, Compliance, and Ease of Use via:

• Dynamic enforcement of zero trust controls like MFA, Just-in-Time Access, etc. without code changes or modifications to resource servers
• A single methodology that works across multiple use cases like Data Security, Software Supply Chain Security, PKI, and PAM
• Integration with on-premise and cloud-based infrastructure such as Hardware Security Modules (HSM), Certificate Authorities (CA), Key Management Systems (KMS), Identity Providers (IdP), Databases, etc.
• Support for both classical and post-quantum cryptography and AI-driven risk

At a time when cryptographic failure can result in catastrophic downtime, regulatory action, or nation-state compromise, Ghesar’s unified, cryptographic-first security approach is not just innovative—it’s indispensable.

The Road Ahead

In an age of exponential digital change, rapid advancement of artificial intelligence, emergence of quantum computing, combined with the explosion in machine and non-human identities, robotics, and autonomous systems – the stakes have never been higher. Our physical and digital worlds are quickly blending into one inseparable reality.

Cryptographic services are not a back-end IT feature relegated to a dark art and a few practitioners. They are fundamental to protecting our future way of life – literally the very foundation on which trust is being built. We must recognize and embrace the critical role these services contribute to our continuous digital interactions and maintaining our everyday social and economic ecosystem.

I joined Ghesar because I believe their vision, technology, and domain expertise are instrumental in solving these current and evolving challenges. Ghesar is providing organizations a strategic “road forward” in enabling and controlling cryptographic services on a tactical and holistic level – and helping them secure the systems that secure our world.

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!