Online Certificate Status Protocol

Last updated
OCSP
Online Certificate Status Protocol
Status Proposed Standard
Year started4 February 2002 (2002-02-04) [1]
First published11 February 2013 (2013-02-11) [1]
Authors
  • Stefan Santesson
  • Michael Myers
  • Rich Ankney
  • Ambarish Malpani
  • Slava Galperin
  • Carlisle Adams
  • Mohit Sahni
Base standards
Domain Digital certificate
Website
  • RFC   6960: OCSP
  • RFC   8954: OCSP Nonce Extension

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. [2] It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). [3] Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

Contents

Some web browsers (e.g., Firefox [4] ) use OCSP to validate HTTPS certificates, while others have disabled it. [5] [6] Most OCSP revocation statuses on the Internet disappear soon after certificate expiration. [7]

Comparison to CRLs

Basic PKI implementation

  1. Alice and Bob have public key certificates issued by Carol, the certificate authority (CA).
  2. Alice wishes to perform a transaction with Bob and sends him her public key certificate.
  3. Bob, concerned that Alice's private key may have been compromised, creates an 'OCSP request' that contains Alice's certificate serial number and sends it to Carol.
  4. Carol's OCSP responder reads the certificate serial number from Bob's request. The OCSP responder uses the certificate serial number to look up the revocation status of Alice's certificate. The OCSP responder looks in a CA database that Carol maintains. In this scenario, Carol's CA database is the only trusted location where a compromise to Alice's certificate would be recorded.
  5. Carol's OCSP responder confirms that Alice's certificate is still OK, and returns a signed, successful 'OCSP response' to Bob.
  6. Bob cryptographically verifies Carol's signed response. Bob has stored Carol's public key sometime before this transaction. Bob uses Carol's public key to verify Carol's response.
  7. Bob completes the transaction with Alice.

Protocol details

An OCSP responder (a server typically run by the certificate issuer) may return a signed response signifying that the certificate specified in the request is 'good', 'revoked', or 'unknown'. If it cannot process the request, it may return an error code.

The OCSP request format supports additional extensions. This enables extensive customization to a particular PKI scheme.

OCSP can be vulnerable to replay attacks, [10] where a signed, 'good' response is captured by a malicious intermediary and replayed to the client at a later date after the subject certificate may have been revoked. OCSP allows a nonce to be included in the request that may be included in the corresponding response. Because of high load, most OCSP responders do not use the nonce extension to create a different response for each request, instead using presigned responses with a validity period of multiple days. Thus, the replay attack is a major threat to validation systems.

OCSP can support more than one level of CA. OCSP requests may be chained between peer responders to query the issuing CA appropriate for the subject certificate, with responders validating each other's responses against the root CA using their own OCSP requests.

An OCSP responder may be queried for revocation information by delegated path validation (DPV) servers. OCSP does not, by itself, perform any DPV of supplied certificates.

The key that signs a response need not be the same key that signed the certificate. The certificate's issuer may delegate another authority to be the OCSP responder. In this case, the responder's certificate (the one that is used to sign the response) must be issued by the issuer of the certificate in question, and must include a certain extension that marks it as an OCSP signing authority (more precisely, an extended key usage extension with the OID {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) keyPurpose(3) ocspSigning(9)})

Privacy concerns

OCSP checking creates a privacy concern for some users, since it requires the client to contact a third party (albeit a party trusted by the client software vendor) to confirm certificate validity. OCSP stapling is a way to verify validity without disclosing browsing behavior to the CA. [2]

Criticisms

OCSP-based revocation is not an effective technique to mitigate against the compromise of an HTTPS server's private key. An attacker who has compromised a server's private key typically needs to be in a man-in-the-middle position on the network to abuse that private key and impersonate a server. An attacker in such a position is also typically in a position to interfere with the client's OCSP queries. Because most clients will silently ignore OCSP if the query times out, OCSP is not a reliable means of mitigating HTTPS server key compromise. [11]

The MustStaple TLS extension in a certificate can require that the certificate be verified by a stapled OCSP response, mitigating this problem. [8] OCSP also remains a valid defense against situations where the attacker is not a "man-in-the-middle" (code-signing or certificates issued in error).

The OCSP protocol assumes the requester has network access to connect to an appropriate OCSP responder. Some requesters may not be able to connect because their local network prohibits direct Internet access (a common practice for internal nodes in a data center). Forcing internal servers to connect to the Internet in order to use OCSP contributes to the de-perimeterisation trend. The OCSP stapling protocol is an alternative that allows servers to cache OCSP responses, which removes the need for the requestor to directly contact the OCSP responder.

Browser support

OCSP information on Firefox 89 Firefox 89 AboutCertificate authority info screenshot.png
OCSP information on Firefox 89

There is wide support for OCSP amongst most major browsers:

However, Google Chrome is an outlier. Google disabled OCSP checks by default in 2012, citing latency and privacy issues [18] and instead uses their own update mechanism to send revoked certificates to the browser. [19]

Implementations

Several open source and proprietary OCSP implementations exist, including fully featured servers and libraries for building custom applications. OCSP client support is built into many operating systems, web browsers, and other network software due to the popularity of HTTPS and the World Wide Web.

Server

Open source

  • Boulder, [20] CA and OCSP responder developed and used by Let's Encrypt (Go)
  • DogTag, [21] Open source certificate authority CA, CRL and OCSP responder.
  • EJBCA, [22] CA and OCSP responder (Java)
  • XiPKI, [23] CA and OCSP responder. With support of RFC 6960 and SHA3 (Java)
  • OpenCA OCSP Responder [24] Standalone OCSP responder from the OpenCA Project (C)

Proprietary

Library

Open source

Client

See also

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

<span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. The purpose of a PKI is to facilitate the secure electronic transfer of information for a range of network activities such as e-commerce, internet banking and confidential email. It is required for activities where simple passwords are an inadequate authentication method and more rigorous proof is required to confirm the identity of the parties involved in the communication and to validate the information being transferred.

In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the device examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

<span class="mw-page-title-main">Root certificate</span> Certificate identifying a root authority

In cryptography and computer security, a root certificate is a public key certificate that identifies a root certificate authority (CA). Root certificates are self-signed and form the basis of an X.509-based public key infrastructure (PKI). Either it has matched Authority Key Identifier with Subject Key Identifier, in some cases there is no Authority Key identifier, then Issuer string should match with Subject string. For instance, the PKIs supporting HTTPS for secure web browsing and electronic signature schemes depend on a set of root certificates.

<span class="mw-page-title-main">Certificate revocation list</span> A list of revoked digital certificates

In cryptography, a certificate revocation list (CRL) is "a list of digital certificates that have been revoked by the issuing certificate authority (CA) before their scheduled expiration date and should no longer be trusted". CRLs are no longer required by the CA/Browser forum, as alternate certificate revocation technologies are increasingly used instead. Nevertheless, CRLs are still widely used by the CAs.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

In cryptography and computer security, self-signed certificates are public key certificates that are not issued by a certificate authority (CA). These self-signed certificates are easy to make and do not cost money. However, they do not provide any trust value.

The certification path validation algorithm is the algorithm which verifies that a given certificate path is valid under a given public key infrastructure (PKI). A path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted certificate authority (CA).

<span class="mw-page-title-main">Network Security Services</span> Collection of cryptographic computer libraries

Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

The Server-based Certificate Validation Protocol (SCVP) is an Internet protocol for determining the path between an X.509 digital certificate and a trusted root and the validation of that path according to a particular validation policy.

<span class="mw-page-title-main">Extended Validation Certificate</span> Certificate for HTTPS websites and software

An Extended Validation Certificate (EV) is a certificate conforming to X.509 that proves the legal entity of the owner and is signed by a certificate authority key that can issue EV certificates. EV certificates can be used in the same manner as any other X.509 certificates, including securing web communications with HTTPS and signing software and documents. Unlike domain-validated certificates and organization-validation certificates, EV certificates can be issued only by a subset of certificate authorities (CAs) and require verification of the requesting entity's legal identity before certificate issuance.

The Online Certificate Status Protocol (OCSP) stapling, formally known as the TLS Certificate Status Request extension, is a standard for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

An offline root certificate authority is a certificate authority which has been isolated from network access, and is often kept in a powered-down state.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 300 million websites, with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan (U-M), and the Linux Foundation.

In public key infrastructure, a validation authority (VA) is an entity that provides a service used to verify the validity or revocation status of a digital certificate per the mechanisms described in the X.509 standard and RFC 5280.

In public key cryptography, a certificate may be revoked before it expires, which signals that it is no longer valid. Without revocation, an attacker could exploit such a compromised or misissued certificate until expiry. Hence, revocation is an important part of a public key infrastructure. Revocation is performed by the issuing certificate authority, which produces a cryptographically authenticated statement of revocation.

References

  1. 1 2 Santesson, Stefan; Myers, Michael; Ankney, Rich; Malpani, Ambarish; Galperin, Slava; Adams, Carlisle (June 2013). "History for draft-ietf-pkix-rfc2560bis-20" . Retrieved December 23, 2021.
  2. 1 2 3 A., Jesin (June 12, 2014). "How To Configure OCSP Stapling on Apache and Nginx". Community Tutorials. Digital Ocean, Inc. Retrieved March 2, 2015.
  3. ↑ "OCSP Stapling". GlobalSign Support. GMO GlobalSign Inc. August 1, 2014. Retrieved March 2, 2015.
  4. ↑ "CA/Revocation Checking in Firefox". wiki.mozilla.org. Retrieved 29 June 2022.
  5. ↑ "Are revoked certificates detected in Safari and Chrome?". 20 September 2017. Retrieved 29 June 2022.
  6. ↑ "CRLSets" . Retrieved 29 June 2022.
  7. ↑ Korzhitskii, Nikita; Carlsson, Niklas (2021). "Revocation Statuses on the Internet". In Hohlfeld, Oliver; Lutu, Andra; Levin, Dave (eds.). Passive and Active Measurement. PAM 2021. LNCS. Vol. 12671. pp. 175–191. arXiv: 2102.04288 . doi:10.1007/978-3-030-72582-2_11. ISBN   978-3-030-72582-2. ISSN   0302-9743.
  8. 1 2 Gibson, Steve. "Security Certificate Revocation Awareness: The case for "OCSP Must-Staple"". Gibson Research Corporation. Retrieved March 2, 2015.
  9. ↑ Keeler, David (July 29, 2013). "OCSP Stapling in Firefox". Mozilla Security Blog. Mozilla Foundation. Retrieved March 2, 2015.
  10. ↑ RFC 6960, section 5, Security Considerations
  11. ↑ "No, Don't Enable Revocation Checking". 19 April 2014. Retrieved 24 April 2014.
  12. ↑ "Windows XP Certificate Status and Revocation Checking". Microsoft . Retrieved 9 May 2016.
  13. ↑ "What's New in Certificate Revocation in Windows Vista and Windows Server 2008". Microsoft. 3 July 2013. Retrieved 9 May 2016.
  14. ↑ "Mozilla Bug 110161 – Enable OCSP by Default". Mozilla. 1 October 2007. Retrieved 18 July 2010.
  15. ↑ Wisniewski, Chester (26 March 2011). "Apple users left to defend themselves against certificate attacks". Sophos . Retrieved 26 March 2011.
  16. ↑ Pettersen, Yngve Nysæter (November 9, 2006). "Introducing Extended Validation Certificates". Opera Software. Archived from the original on 10 February 2010. Retrieved 8 January 2010.
  17. ↑ Pettersen, Yngve Nysæter (3 July 2008). "Rootstore newsletter". Opera Software . Retrieved 8 January 2010.
  18. ↑ Langley, Adam (5 Feb 2012). "Revocation checking and Chrome's CRL". Archived from the original on 2012-02-12. Retrieved 2015-01-30.
  19. ↑ "Chrome does certificate revocation better", April 21, 2014, Larry Seltzer, ZDNet
  20. ↑ "Boulder – an ACME CA". GitHub . 16 March 2018. Retrieved 17 March 2018.
  21. ↑ "Dogtag Certificate System" . Retrieved 12 Aug 2019.
  22. ↑ "EJBCA – Open Source PKI Certificate Authority". PrimeKey. 2 February 2018. Retrieved 17 March 2018.
  23. ↑ "XiPKI". GitHub. 13 March 2018. Retrieved 17 March 2018.
  24. ↑ "OpenCA OCSP" . Retrieved 3 January 2024.
  25. ↑ "Certificate Services (Windows)". Windows Dev Center. Microsoft. 2018. Retrieved 17 March 2018.
  26. ↑ "Package ocsp". cfssl GoDoc. 25 February 2018. Retrieved 17 March 2018.
  27. ↑ "OCSP_response_status". master manpages. OpenSSL. 2017. Retrieved 17 March 2018.
  28. ↑ "OCSP in wolfSSL Embedded SSL – wolfSSL". 2014-01-27. Retrieved 2019-01-25.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.