Hubbry Logo
Public key certificatePublic key certificateMain
Open search
Public key certificate
Community hub
Public key certificate
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Public key certificate
Public key certificate
Public key certificate
View on Wikipedia
from Wikipedia

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.[1][2] The certificate includes the public key and information about it, information about the identity of its owner (called the subject), and the digital signature of an entity that has verified the certificate's contents (called the issuer). 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 a typical public-key infrastructure (PKI) scheme, the certificate issuer is a certificate authority (CA),[3] usually a company that charges customers a fee to issue certificates for them. By contrast, in a web of trust scheme, individuals sign each other's keys directly, in a format that performs a similar function to a public key certificate. In case of key compromise, a certificate may need to be revoked.

The most common format for public key certificates is defined by X.509. Because X.509 is very general, the format is further constrained by profiles defined for certain use cases, such as Public Key Infrastructure (X.509).[4]

Chain of trust

[edit]
The roles of root certificate, intermediate certificate and end-entity certificate as in the chain of trust.
Main articles: Chain of trust and Trust anchor

The digital certificate system is a chain of trust, meaning most certificates can be validated against parent certificates. The chain starts with a root certificate, which serves as a trust anchor (a.k.a. root of trust). This certificate is self-signed (see below) and has no parent. The issuing certificate authority uses other methods to safeguard and validate this certificate.

An intermediate certificate has a similar purpose to the root certificate – its only use is to sign other certificates. However, an intermediate certificate is not self-signed. A root certificate or another intermediate certificate needs to sign it.

An end-entity certificate or leaf certificate is any certificate that cannot sign other certificates. For instance, TLS/SSL server and client certificates, email certificates, code signing certificates, and qualified certificates are all end-entity certificates.

Types of certificate

[edit]

TLS/SSL server certificate

[edit]

The Transport Layer Security (TLS) protocol – as well as its outdated predecessor, the Secure Sockets Layer (SSL) protocol – ensures that the communication between a client computer and a server is secure. The protocol requires the server to present a digital certificate, proving that it is the intended destination. The connecting client conducts certification path validation, ensuring that:

  1. The subject of the certificate matches the hostname (not to be confused with the domain name) to which the client is trying to connect.
  2. A trusted certificate authority has signed the certificate.

The Subject field of the certificate must identify the primary hostname of the server as the Common Name. This means that the name listed in the certificate should exactly match the domain name users connect to (for example, www.example.com), ensuring that the certificate is valid for that specific hostname.[5] The hostname must be publicly accessible, not using private addresses or reserved domains.[6] A certificate may be valid for multiple hostnames (e.g., a domain and its subdomains). Such certificates are commonly called Subject Alternative Name (SAN) certificates or Unified Communications Certificates (UCC). These certificates contain the Subject Alternative Name field, though many CAs also put them into the Subject Common Name field for backward compatibility. If some of the hostnames contain an asterisk (*), a certificate may also be called a wildcard certificate.

Once the certification path validation is successful, the client can establish an encrypted connection with the server.

Internet-facing servers, such as public Web servers, must obtain their certificates from a trusted, public certificate authority (CA).

TLS/SSL client certificate

[edit]

Client certificates authenticate the client connecting to a TLS service, for instance to provide access control. Because most services provide access to individuals, rather than devices, most client certificates contain an email address or personal name rather than a hostname. In addition, the certificate authority that issues the client certificate is usually the service provider to which client connects because it is the provider that needs to perform authentication. Some service providers even offer free SSL certificates as part of their packages.[7]

While most web browsers support client certificates, the most common form of authentication on the Internet is a username and password pair. Client certificates are more common in virtual private networks (VPN) and Remote Desktop Services, where they authenticate devices.

Email certificate

[edit]

In accordance with the S/MIME protocol, email certificates can both establish the message integrity and encrypt messages. To establish encrypted email communication, the communicating parties must have their digital certificates in advance. Each must send the other one digitally signed email and opt to import the sender's certificate.

Some publicly trusted certificate authorities provide email certificates, but more commonly S/MIME is used when communicating within a given organization, and that organization runs its own CA, which is trusted by participants in that email system.

Self-signed certificate

[edit]
Main article: Self-signed certificate

A self-signed certificate is a certificate with a subject that matches its issuer, and a signature that can be verified by its own public key.

Although this type of certificate is worthless for establishing remote trust between unacquainted parties, it has full trust value when the issuer and the sole user are the same entity. As discussed above (in § Chain of trust), a root certificate is a self-signed certificate. The certificate authority, which is the sole user of the certificate, uses other means to validate and safeguard it. Another example is the Encrypting File System on Microsoft Windows, which issues a self-signed certificate on behalf of the encrypting user, and uses it to transparently decrypt data on the fly.

Subject Alternative Name certificate

[edit]
An example of a Subject Alternative Name section for domain names owned by the Wikimedia Foundation

Subject Alternative Name (SAN) certificates are an extension to X.509 that allows various values to be associated with a security certificate using a subjectAltName field.[8] These values are called Subject Alternative Names (SANs). Names include:[4]: §4.2.1.6 

As of May 2000, Subject Alternative Names are the preferred method of adding DNS names to certificates.[9] The previous method of putting DNS names in the commonName field is now deprecated.[10] Google Chrome version 58 (March 2017) removed support for checking the commonName field at all, instead only looking at the SANs.[10] As shown in the picture of Wikimedia's section on the right, the SAN field can contain wildcards.[11] Not all vendors support or endorse mixing wildcards into SAN certificates.[12]

Wildcard certificate

[edit]
An example of a wildcard certificate on comifuro.net (note the asterisk: *)

A public key certificate which uses an asterisk * (the wildcard) in its domain name fragment is called a Wildcard certificate. Through the use of *, a single certificate may be used for multiple sub-domains. It is commonly used for transport layer security in computer networking.

For example, a single wildcard certificate for https://*.example.com will secure all these subdomains on the https://*.example.com domain:

  • payment.example.com
  • contact.example.com
  • login-secure.example.com
  • www.example.com

Instead of getting separate certificates for subdomains, you can use a single certificate for all main domains and subdomains and reduce cost.[13]

Because the wildcard only covers one level of subdomains (the asterisk doesn't match full stops),[14] these domains would not be valid for the certificates:[15]

  • test.login.example.com
  • example.com

Note possible exceptions by CAs, for example wildcard-plus cert by DigiCert contains an automatic "Plus" property for the naked domain example.com.[citation needed]

Limitations

[edit]

Only a single level of subdomain matching is supported.[14][16]

It is not possible to get a wildcard for an Extended Validation Certificate.[17] A workaround could be to add every virtual host name in the Subject Alternative Name (SAN) extension,[18][19] the major problem being that the certificate needs to be reissued whenever a new virtual server is added. (See Transport Layer Security § Support for name-based virtual servers for more information.)

Wildcards can be added as domains in multi-domain certificates or Unified Communications Certificates (UCC). In addition, wildcards themselves can have subjectAltName extensions, including other wildcards. For example, the wildcard certificate *.wikipedia.org has *.m.wikimedia.org as a Subject Alternative Name. Thus it secures www.wikipedia.org as well as the completely different website name meta.m.wikimedia.org.[20]

RFC 6125 argues against wildcard certificates on security grounds, in particular "partial wildcards".[21]

Further examples

[edit]

The wildcard applies only to one level of the domain name. *.example.com matches sub1.example.com but not example.com and not sub2.sub1.domain.com

Early specifications[9] allowed the wildcard to appear anywhere inside a label as a "partial wildcard":

f*.domain.com is OK. It will match frog.domain.com but not frog.super.domain.com
baz*.example.net is OK and matches baz1.example.net
*baz.example.net is OK and matches foobaz.example.net
b*z.example.net is OK and matches buzz.example.net

However, use of "partial-wildcard" certs is not recommended. As of 2011, partial wildcard support is optional, and is explicitly disallowed in SubjectAltName headers that are required for multi-name certificates.[22]: §6.3  All major browsers have deliberately removed support for partial-wildcard certificates;[23][24] they will result in a "SSL_ERROR_BAD_CERT_DOMAIN" error. Similarly, it is typical for standard libraries in programming languages to not support "partial-wildcard" certificates. For example, any "partial-wildcard" certificate will not work with the latest versions of both Python[25] and Go. Thus,

Do not allow a label that consists entirely of just a wildcard unless it is the left-most label

sub1.*.domain.com is not allowed.

A cert with multiple wildcards in a name is not allowed.

*.*.domain.com

A cert with * plus a top-level domain is not allowed.

*.com

Too general and should not be allowed.

*

International domain names encoded in ASCII (A-label) are labels that are ASCII-encoded and begin with xn--. URLs with international labels cannot contain wildcards.[26]

xn--caf-dma.com is café.com
xn--caf-dma*.com is not allowed
Lw*.xn--caf-dma.com is allowed

Other certificates

[edit]
  • EMV certificate: EMV is a payment method based on a technical standard for payment cards, payment terminals and automated teller machines (ATM). EMV payment cards are preloaded with a card issuer certificate, signed by the EMV certificate authority[27] to validate authenticity of the payment card during the payment transaction.
  • Code-signing certificate: Certificates can validate apps (or their binaries) to ensure they were not tampered with during delivery.
  • Qualified certificate: A certificate identifying an individual, typically for electronic signature purposes. These are most commonly used in Europe, where the eIDAS regulation standardizes them and requires their recognition.
  • Role-based certificate: Defined in the X.509 Certificate Policy for the Federal Bridge Certification Authority (FBCA), role-based certificates "identify a specific role on behalf of which the subscriber is authorized to act rather than the subscriber’s name and are issued in the interest of supporting accepted business practices."[28]
  • Group certificate: Defined in the X.509 Certificate Policy for the Federal Bridge Certification Authority (FBCA), for "cases where there are several entities acting in one capacity, and where non-repudiation for transactions is not desired."[29]

Common fields

[edit]
See also: X.509 § Structure of a certificate

These are some of the most common fields in certificates. Most certificates contain a number of fields not listed here. Note that in terms of a certificate's X.509 representation, a certificate is not "flat" but contains these fields nested in various structures within the certificate.

  • Serial Number: Used to uniquely identify the certificate within a CA's systems. In particular this is used to track revocation information.
  • Subject: The entity a certificate belongs to: a machine, an individual, or an organization.
  • Issuer: The entity that verified the information and signed the certificate.
  • Not Before: The earliest time and date on which the certificate is valid. Usually set to a few hours or days prior to the moment the certificate was issued, to avoid clock skew problems.
  • Not After: The time and date past which the certificate is no longer valid.
  • Key Usage: The valid cryptographic uses of the certificate's public key. Common values include digital signature validation, key encipherment, and certificate signing.
  • Extended Key Usage: The applications in which the certificate may be used. Common values include TLS server authentication, email protection, and code signing.
  • Public Key: A public key belonging to the certificate subject.
  • Signature Algorithm: This contain a hashing algorithm and a digital signature algorithm. For example "sha256RSA" where sha256 is the hashing algorithm and RSA is the signature algorithm.
  • Signature: The body of the certificate is hashed (hashing algorithm in "Signature Algorithm" field is used) and then the hash is signed (signature algorithm in the "Signature Algorithm" field is used) with the issuer's private key.

Example

[edit]

This is an example of a decoded SSL/TLS certificate retrieved from SSL.com's website. The issuer's common name (CN) is shown as SSL.com EV SSL Intermediate CA RSA R3, identifying this as an Extended Validation (EV) certificate. Validated information about the website's owner (SSL Corp) is located in the Subject field. The X509v3 Subject Alternative Name field contains a list of domain names covered by the certificate. The X509v3 Extended Key Usage and X509v3 Key Usage fields show all appropriate uses. 

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            72:14:11:d3:d7:e0:fd:02:aa:b0:4e:90:09:d4:db:31
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Texas, L=Houston, O=SSL Corp, CN=SSL.com EV SSL Intermediate CA RSA R3
        Validity
            Not Before: Apr 18 22:15:06 2019 GMT
            Not After : Apr 17 22:15:06 2021 GMT
        Subject: C=US, ST=Texas, L=Houston, O=SSL Corp/serialNumber=NV20081614243, CN=www.ssl.com/postalCode=77098/businessCategory=Private Organization/street=3100 Richmond Ave/jurisdictionST=Nevada/jurisdictionC=US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:ad:0f:ef:c1:97:5a:9b:d8:1e ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:BF:C1:5A:87:FF:28:FA:41:3D:FD:B7:4F:E4:1D:AF:A0:61:58:29:BD

            Authority Information Access: 
                CA Issuers - URI:http://www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt
                OCSP - URI:http://ocsps.ssl.com

            X509v3 Subject Alternative Name: 
                DNS:www.ssl.com, DNS:answers.ssl.com, DNS:faq.ssl.com, DNS:info.ssl.com, DNS:links.ssl.com, DNS:reseller.ssl.com, DNS:secure.ssl.com, DNS:ssl.com, DNS:support.ssl.com, DNS:sws.ssl.com, DNS:tools.ssl.com
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.1
                Policy: 1.2.616.1.113527.2.5.1.1
                Policy: 1.3.6.1.4.1.38064.1.1.1.5
                  CPS: https://www.ssl.com/repository

            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl

            X509v3 Subject Key Identifier: 
                E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 87:75:BF:E7:59:7C:F8:8C:43:99 ...
                    Timestamp : Apr 18 22:25:08.574 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:40:51:53:90:C6:A2 ...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : A4:B9:09:90:B4:18:58:14:87:BB ...
                    Timestamp : Apr 18 22:25:08.461 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:43:80:9E:19:90:FD ...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 55:81:D4:C2:16:90:36:01:4A:EA ...
                    Timestamp : Apr 18 22:25:08.769 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:C1:3E:9F:F0:40 ...
    Signature Algorithm: sha256WithRSAEncryption
         36:07:e7:3b:b7:45:97:ca:4d:6c ...

Usage in the European Union

[edit]

In the European Union, (advanced) electronic signatures on legal documents are commonly performed using digital signatures with accompanying identity certificates. However, only qualified electronic signatures (which require using a qualified trust service provider and signature creation device) are given the same power as a physical signature.

Certificate authorities

[edit]
Main article: Certificate authority
The procedure of obtaining a Public key certificate

In the X.509 trust model, a certificate authority (CA) is responsible for signing certificates. These certificates act as an introduction between two parties, which means that a CA acts as a trusted third party. A CA processes requests from people or organizations requesting certificates (called subscribers), verifies the information, and potentially signs an end-entity certificate based on that information. To perform this role effectively, a CA needs to have one or more broadly trusted root certificates or intermediate certificates and the corresponding private keys. CAs may achieve this broad trust by having their root certificates included in popular software, or by obtaining a cross-signature from another CA delegating trust. Other CAs are trusted within a relatively small community, like a business, and are distributed by other mechanisms like Windows Group Policy.

Certificate authorities are also responsible for maintaining up-to-date revocation information about certificates they have issued, indicating whether certificates are still valid. They provide this information through Online Certificate Status Protocol (OCSP) and/or Certificate Revocation Lists (CRLs). Some of the larger certificate authorities in the market include IdenTrust, DigiCert, and Sectigo.[30]

Root programs

[edit]

Some major software contain a list of certificate authorities that are trusted by default.[citation needed] This makes it easier for end-users to validate certificates, and easier for people or organizations that request certificates to know which certificate authorities can issue a certificate that will be broadly trusted. This is particularly important in HTTPS, where a web site operator generally wants to get a certificate that is trusted by nearly all potential visitors to their web site.

The policies and processes a provider uses to decide which certificate authorities their software should trust are called root programs. The most influential root programs are:[citation needed]

Browsers other than Firefox generally use the operating system's facilities to decide which certificate authorities are trusted. So, for instance, Chrome on Windows trusts the certificate authorities included in the Microsoft Root Program, while on macOS or iOS, Chrome trusts the certificate authorities in the Apple Root Program.[31] Edge and Safari use their respective operating system trust stores as well, but each is only available on a single OS. Firefox uses the Mozilla Root Program trust store on all platforms.

The Mozilla Root Program is operated publicly, and its certificate list is part of the open source Firefox web browser, so it is broadly used outside Firefox.[citation needed] For instance, while there is no common Linux Root Program, many Linux distributions, like Debian,[32] include a package that periodically copies the contents of the Firefox trust list, which is then used by applications.

Root programs generally provide a set of valid purposes with the certificates they include. For instance, some CAs may be considered trusted for issuing TLS server certificates, but not for code signing certificates. This is indicated with a set of trust bits in a root certificate storage system.

Revocation

[edit]
Main article: Certificate revocation

A certificate may be revoked before it expires, which signals that it is no longer valid. Without revocation, an attacker would be able to exploit such a compromised or misissued certificate until expiry.[33] Hence, revocation is an important part of a public key infrastructure.[34] Revocation is performed by the issuing certificate authority, which produces a cryptographically authenticated statement of revocation.[35]

For distributing revocation information to clients, timeliness of the discovery of revocation (and hence the window for an attacker to exploit a compromised certificate) trades off against resource usage in querying revocation statuses and privacy concerns.[36] If revocation information is unavailable (either due to accident or an attack), clients must decide whether to fail-hard and treat a certificate as if it is revoked (and so degrade availability) or to fail-soft and treat it as unrevoked (and allow attackers to sidestep revocation).[37]

Due to the cost of revocation checks and the availability impact from potentially-unreliable remote services, Web browsers limit the revocation checks they will perform, and will fail-soft where they do.[38] Certificate revocation lists are too bandwidth-costly for routine use, and the Online Certificate Status Protocol presents connection latency and privacy issues. Other schemes have been proposed but have not yet been successfully deployed to enable fail-hard checking.[34]

Website security

[edit]

The most common use of certificates is for HTTPS-based web sites. A web browser validates that an HTTPS web server is authentic, so that the user can feel secure that his/her interaction with the web site has no eavesdroppers and that the web site is who it claims to be. This security is important for electronic commerce. In practice, a web site operator obtains a certificate by applying to a certificate authority with a certificate signing request. The certificate request is an electronic document that contains the web site name, company information and the public key. The certificate provider signs the request, thus producing a public certificate. During web browsing, this public certificate is served to any web browser that connects to the web site and proves to the web browser that the provider believes it has issued a certificate to the owner of the web site.

As an example, when a user connects to https://www.example.com/ with their browser, if the browser does not give any certificate warning message, then the user can be theoretically sure that interacting with https://www.example.com/ is equivalent to interacting with the entity in contact with the email address listed in the public registrar under "example.com", even though that email address may not be displayed anywhere on the web site.[citation needed] No other surety of any kind is implied. Further, the relationship between the purchaser of the certificate, the operator of the web site, and the generator of the web site content may be tenuous and is not guaranteed.[citation needed] At best, the certificate guarantees uniqueness of the web site, provided that the web site itself has not been compromised (hacked) or the certificate issuing process subverted.

A certificate provider can opt to issue three types of certificates, each requiring its own degree of vetting rigor. In order of increasing rigor (and naturally, cost) they are: Domain Validation, Organization Validation and Extended Validation. These rigors are loosely agreed upon by voluntary participants in the CA/Browser Forum.[citation needed]

Validation levels

[edit]

Domain validation

[edit]
Main article: Domain-validated certificate

A certificate provider will issue a domain-validated (DV) certificate to a purchaser if the purchaser can demonstrate one vetting criterion: the right to administratively manage the affected DNS domain(s).

Organization validation

[edit]

A certificate provider will issue an organization validation (OV) class certificate to a purchaser if the purchaser can meet two criteria: the right to administratively manage the domain name in question, and perhaps, the organization's actual existence as a legal entity. A certificate provider publishes its OV vetting criteria through its certificate policy.

Extended validation

[edit]
Main article: Extended Validation Certificate

To acquire an Extended Validation (EV) certificate, the purchaser must persuade the certificate provider of its legal identity, including manual verification checks by a human. As with OV certificates, a certificate provider publishes its EV vetting criteria through its certificate policy.

Until 2019, major browsers such as Chrome and Firefox generally offered users a visual indication of the legal identity when a site presented an EV certificate. This was done by showing the legal name before the domain, and a bright green color to highlight the change. Most browsers deprecated this feature[39][40] providing no visual difference to the user on the type of certificate used. This change followed security concerns raised by forensic experts and successful attempts to purchase EV certificates to impersonate famous organizations, proving the inefficiency of these visual indicators and highlighting potential abuses.[41]

Weaknesses

[edit]

A web browser will give no warning to the user if a web site suddenly presents a different certificate, even if that certificate has a lower number of key bits, even if it has a different provider, and even if the previous certificate had an expiry date far into the future.[citation needed] Where certificate providers are under the jurisdiction of governments, those governments may have the freedom to order the provider to generate any certificate, such as for the purposes of law enforcement. Subsidiary wholesale certificate providers also have the freedom to generate any certificate.

All web browsers come with an extensive built-in list of trusted root certificates, many of which are controlled by organizations that may be unfamiliar to the user.[1] Each of these organizations is free to issue any certificate for any web site and have the guarantee that web browsers that include its root certificates will accept it as genuine. In this instance, end users must rely on the developer of the browser software to manage its built-in list of certificates and on the certificate providers to behave correctly and to inform the browser developer of problematic certificates. While uncommon, there have been incidents in which fraudulent certificates have been issued: in some cases, the browsers have detected the fraud; in others, some time passed before browser developers removed these certificates from their software.[42][43]

The list of built-in certificates is also not limited to those provided by the browser developer: users (and to a degree applications) are free to extend the list for special purposes such as for company intranets.[44] This means that if someone gains access to a machine and can install a new root certificate in the browser, that browser will recognize websites that use the inserted certificate as legitimate.

For provable security, this reliance on something external to the system has the consequence that any public key certification scheme has to rely on some special setup assumption, such as the existence of a certificate authority.[45]

Usefulness versus unsecured web sites

[edit]

In spite of the limitations described above, certificate-authenticated TLS is considered mandatory by all security guidelines whenever a web site hosts confidential information or performs material transactions. This is because, in practice, in spite of the weaknesses described above, web sites secured by public key certificates are still more secure than unsecured http:// web sites.[46]

Standards

[edit]

The National Institute of Standards and Technology (NIST) Computer Security Division[47] provides guidance documents for public key certificates:

  • SP 800-32 Introduction to Public Key Technology and the Federal PKI Infrastructure[48]
  • SP 800-25 Federal Agency Use of Public Key Technology for Digital Signatures and Authentication[49]

See also

[edit]

References

[edit]

Works cited

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Public key certificate

View on Grokipedia
from Grokipedia
A public key certificate is a digitally signed electronic document that binds a public cryptographic key to the identity of an entity—such as a person, organization, device, or service—through the use of a trusted third party's signature, enabling secure authentication and key distribution in networked environments. Standardized in the X.509 format by the International Telecommunication Union (ITU-T) since 1988, it serves as a foundational component of public key infrastructure (PKI) systems, which manage the lifecycle of digital certificates to support confidentiality, integrity, and non-repudiation in electronic transactions. The structure of an public key certificate follows an ASN.1-based syntax, consisting of a to-be-signed portion (TBSCertificate) and a . Key fields in the TBSCertificate include the version (typically v3 for modern use), a unique assigned by the issuer, the algorithm identifier, the issuer's distinguished name, the validity period (notBefore and notAfter dates), the subject's distinguished name, the subject public key information (including the algorithm and key value), and optional extensions for attributes like key usage or subject alternative names; the entire TBSCertificate is then signed using the issuer's private key to ensure authenticity and integrity. Issued by a certification authority (CA)—an entity responsible for verifying identities and maintaining trust chains—certificates can be validated through certification paths that trace back to a trusted CA, often using certificate revocation lists (CRLs) or (OCSP) to check for revocation. Public key certificates underpin numerous security protocols and applications, including (TLS) for encrypting web traffic and verifying server identities, for securing virtual private networks (VPNs), and for digitally signing and encrypting messages. In broader PKI deployments, they facilitate secure software distribution, , and in enterprise environments, with federal and international standards ensuring interoperability and compliance across domains like , government systems, and IoT devices.

Fundamentals

Definition and Purpose

A public key certificate is a digital document that binds a public key to an identity—such as a person, organization, or device—through a digital signature from a trusted issuer, typically containing the subject's identification, the public key itself, and the issuer's signature to affirm the binding. This structure ensures that the public key can be reliably associated with its claimed owner, as the issuer's private key signs the certificate to prevent forgery. In (PKI), the primary purpose of a public key certificate is to enable by allowing recipients to verify the authenticity of a public key, thereby preventing man-in-the-middle attacks where an adversary might substitute a fraudulent key. Certificates support key PKI functions, including for confidentiality, digital signatures for and , and overall trust in electronic transactions. The basic workflow involves a obtaining a certificate during asymmetric operations, such as establishing a secure session, where they validate the issuer's using the issuer's public key (often via a chain of certificates) to confirm the subject's public key legitimacy before proceeding with or verification. Key benefits include establishing trust through verifiable chains of authority, ensuring by linking actions to authenticated identities, and providing assurance of in digital interactions.

History and Development

The development of public key certificates traces its roots to the emergence of asymmetric cryptography in the 1970s, which addressed longstanding challenges in secure over untrusted networks. In 1976, and published "New Directions in Cryptography," introducing the and proposing public key distribution systems as a solution to the problem of securely sharing cryptographic keys without prior secrets. This foundational work laid the groundwork for public key infrastructures (PKI), where certificates would later bind public keys to identities. Building on this, , , and developed the RSA algorithm in 1977, providing a practical method for public key encryption and digital signatures that would become integral to certificate mechanisms. Early standardization efforts formalized the concept of certificates in the late 1980s and early 1990s. The (ITU-T, formerly CCITT) published the standard in 1988 as part of the directory services framework, defining a structure for public key certificates issued by trusted authorities to verify entity identities. Initial widespread adoption occurred in authentication systems like Kerberos, developed at MIT in the 1980s with version 5 released in 1993, which initially used symmetric cryptography but later incorporated public key extensions such as PKINIT (RFC 4556, 2006) for certificate-based authentication. Complementing this, released (PGP) in 1991, introducing a decentralized "web of trust" model for certificate-like key bindings in , challenging centralized authority models. Key milestones in the propelled certificates into mainstream use, particularly for web security. introduced the Secure Sockets Layer (SSL) protocol in 1994 (with version 2.0 publicly released in 1995), incorporating certificates to enable encrypted browser-server communications and authenticate websites. This innovation fueled the growth of in the late 1990s, as businesses adopted SSL certificates to secure online transactions amid rising internet adoption. To harmonize practices, the formed in 2005, establishing baseline requirements for certificate issuance and validation to enhance trust and interoperability across browsers and authorities. Recent advancements have focused on automation and future-proofing against quantum threats. The Automated Certificate Management Environment (ACME) protocol was developed by the IETF starting in 2015 and standardized in 2019 (RFC 8555), enabling automated issuance and renewal of certificates; this underpinned the launch of Let's Encrypt, a free CA that issued its first certificates in late 2015 and dramatically increased HTTPS adoption by simplifying deployment. By 2024, concerns over quantum computing vulnerabilities prompted the National Institute of Standards and Technology (NIST) to finalize post-quantum cryptographic standards (FIPS 203, 204, and 205), incorporating algorithms like ML-KEM and ML-DSA for use in certificate signatures and key exchange to ensure long-term security. In 2025, NIST selected additional algorithms such as HQC for standardization in March, and implementations advanced with post-quantum cryptography APIs becoming generally available in Microsoft Windows via the November update.

Structure and Components

Key Fields

A public key certificate in the format is structured as a sequence of three primary components: the To Be Signed Certificate (TBSCertificate), which holds the certificate's content; the signature algorithm identifier, specifying the cryptographic algorithm used for signing; and the signature value, containing the issuer's digital signature. The TBSCertificate encapsulates the core fields that define the certificate's identity, validity, and key information, while also supporting optional extensions in version 3 (v3) certificates to convey additional attributes. This structure ensures interoperability in (PKI) systems. The version field indicates the version of the certificate and is explicitly tagged when greater than (v1); version 3 is the standard for modern certificates, enabling the use of extensions. The is a unique positive up to 20 octets long, assigned by the to distinguish this certificate from others it has issued. The field within the TBSCertificate identifies and parameters used by the for signing, such as RSA with SHA-256, and mirrors the top-level signature algorithm identifier. The field contains the distinguished name (DN) of the issuing (CA), formatted as a sequence of relative distinguished names (RDNs) like country (C), organization (O), and (CN). The validity period is defined by two fields: notBefore, the date and time from which the certificate is valid, and notAfter, the date and time after which it expires; these are encoded as UTCTime or GeneralizedTime. The subject field holds the DN of the entity to which the certificate is issued, following the same format as the issuer. The subject public key info field includes the algorithm identifier (e.g., RSA, ECDSA) and parameters for the subject's public key, followed by the key value itself in bit string format. Additionally, version 2 (v2) and later certificates may include optional issuer unique ID and subject unique ID fields, which are bit strings used to distinguish instances of the same name, though they are deprecated in current profiles. Version 3 certificates feature an extensions field, a sequence of optional attributes that enhance functionality without altering the core structure; each extension has an (OID), criticality flag (indicating if non-supporting systems must reject the certificate), and value. The basic constraints extension specifies whether the subject can act as a CA (via a boolean flag) and, if so, the maximum length of the certification path from that CA; it is typically critical in CA certificates. The key usage extension enumerates permissible operations for the public key, such as , content commitment (), key encipherment, data encipherment, key agreement, certificate signing, CRL signing, encipher-only, or decipher-only, using a bit string; it is often marked critical to enforce restrictions. The extended key usage extension provides application-specific purposes beyond basic key usage, such as server , client , , protection, or time stamping, identified by OIDs; it refines rather than overrides key usage. The subject alternative name (SAN) extension binds additional identities to the subject, including DNS names, IP addresses, registered IDs, URIs, or other names, allowing flexibility beyond the single subject DN; it is frequently used in TLS certificates. The digital signature process involves hashing the DER-encoded TBSCertificate and signing the result with the issuer's private key using the algorithm specified in the signature field; the resulting signatureValue is a bit string appended to the certificate, enabling verification of authenticity and integrity by relying parties using the issuer's public key. Certificates are encoded using Abstract Syntax Notation One () with Distinguished Encoding Rules (DER), producing a deterministic binary representation suitable for digital signatures and transmission. For human-readable or email-friendly formats, the DER binary is base64-encoded and delimited with headers and footers in (PEM) format, such as "-----BEGIN CERTIFICATE-----" followed by the encoded data and "-----END CERTIFICATE-----".

Certificate Example

To illustrate the structure of a public key certificate, consider the following fictional TLS server certificate in version 3 format, as specified in RFC 5280. This example decodes to key fields as follows (values are illustrative):
  • Version: v3 (explicitly tagged as 2)
  • Serial Number: 1234567890 (a unique positive integer)
  • Signature Algorithm: sha256WithRSAEncryption
  • Issuer DN: C=, O=Sample CA, CN=Sample CA
  • Validity: notBefore=2025-01-01 00:00:00 UTC, notAfter=2026-01-01 00:00:00 UTC
  • Subject DN: C=, O=Example Inc., CN=example.com
  • Subject Public Key Info: Algorithm=rsaEncryption (OID 1.2.840.113549.1.1.1), Key= (2048-bit RSA public key modulus and exponent, omitted for brevity)
  • Extensions:
    • Basic Constraints: CA=FALSE (critical)
    • Key Usage: digitalSignature, keyEncipherment (critical)
    • Extended Key Usage: serverAuth (OID 1.3.6.1.5.5.7.3.1)
    • Subject Alternative Name: DNS=example.com, DNS=www.example.com
In PEM format, this would appear as base64-encoded DER data wrapped in "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" headers, with the full binary verifiable against the above fields using tools like .

Types of Certificates

Server Certificates for TLS/SSL

Server certificates for TLS/SSL are digital certificates specifically designed to authenticate the identity of a server during the (TLS) or Secure Sockets Layer (SSL) handshake process, thereby enabling secure, encrypted connections such as for . In the TLS protocol, the server presents its certificate to the client as part of the , allowing the client to verify the server's public key and domain ownership against trusted certificate authorities (CAs) before proceeding with and session establishment. This authentication step is crucial for preventing man-in-the-middle attacks and ensuring that sensitive data, like user credentials or financial information, is transmitted only to the legitimate server. These certificates are typically issued by public CAs that are trusted by major browsers and operating systems, ensuring broad compatibility and reliability in production environments. A key characteristic is the inclusion of the server authentication purpose in the Extended Key Usage (EKU) extension, which explicitly designates the certificate for authenticating servers in TLS connections, as defined in standards like RFC 5280. Many server certificates also incorporate the Subject Alternative Name (SAN) extension to cover multiple domain names or IP addresses under a single certificate, facilitating management for complex web deployments such as content delivery networks or multi-subdomain sites. This design supports scalability while maintaining security, with the certificate often including intermediate CAs traceable to a trusted root. The issuance process for server certificates emphasizes domain validation (DV) to confirm control over the requested domain, typically through automated methods like email verification to administrative contacts or DNS challenges where the applicant adds a specific . These methods, outlined in the CA/Browser Forum's Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, allow for rapid issuance—often within minutes—without requiring extensive identity proofing, making DV suitable for most use cases. Certificates integrate seamlessly with modern protocols like TLS 1.3, which mandates exchanges for , ensuring that even if long-term keys are compromised, past sessions remain secure. Deployment involves configuring the private key and certificate on web servers such as or , where they are loaded into the server's SSL/TLS module to handle incoming connections. For enhanced security, server operators may implement certificate pinning, which specifies expected certificate details in client applications to prevent reliance on potentially compromised CAs. This practice, while reducing flexibility, bolsters protection against supply chain attacks in critical infrastructures.

Client Certificates for TLS/SSL

Client certificates in TLS/SSL enable by allowing clients to prove their identity to servers during secure connections, complementing server authentication in the TLS process. In this mode, the server requests a client certificate, which the client presents along with a generated using its corresponding private key to demonstrate possession and authenticity. This bidirectional verification enhances security beyond unilateral server authentication, reducing risks from impersonation in sensitive communications. These certificates are widely used in enterprise environments for verifying user or device identities in virtual private networks (VPNs), where they facilitate secure remote access without relying solely on passwords. In (IoT) deployments, client certificates authenticate devices to central gateways or cloud services, ensuring only authorized endpoints can join networks. Similarly, in secure application programming interfaces (APIs), mutual TLS (mTLS) with client certificates enforces strict for machine-to-machine interactions, such as in architectures. A key characteristic of client certificates is the inclusion of the Extended Key Usage (EKU) extension in their structure, specifying the object identifier 1.3.6.1.5.5.7.3.2 (id-kp-clientAuth) to denote their purpose for TLS client authentication. This extension helps relying parties validate the certificate's intended application, preventing misuse in other contexts like server authentication. Deployment typically involves hardware-based solutions, such as smart cards that store the private key in tamper-resistant chips to protect against extraction, or software-based options like operating system keystores (e.g., Windows Certificate Store) and application-specific stores (e.g., ), which offer convenience but require additional safeguards against key compromise. For heightened security, client certificates often feature shorter validity periods—commonly 1 to 3 years—compared to some other certificate types, limiting the window of exposure if a private key is breached. Support for client certificates is integral to TLS , as defined in protocols like TLS 1.2 and 1.3, where the client responds to the server's CertificateRequest with a Certificate message containing the chain and a CertificateVerify message signed by the private key. Protocols such as (FTP over TLS) leverage this capability to secure file transfers with optional client , ensuring both endpoints are trusted before exchange begins. Managing client certificates at scale presents significant challenges, particularly in distribution and revocation. Distributing certificates to numerous clients—such as employees' devices or IoT fleets—requires automated mechanisms like (EMM) tools or (PKI) integration to avoid manual errors and ensure timely provisioning without exposing private keys. Revocation, necessary when keys are compromised or users depart, relies on mechanisms like Certificate Revocation Lists (CRLs) or the (OCSP), but propagating updates across global networks can introduce latency, potentially leaving systems vulnerable until checks occur. Organizations must implement robust monitoring and policy enforcement to address these issues, as lapses can undermine the entire framework.

Email Certificates

Email certificates, also known as certificates, are public key certificates specifically designed to secure email communications by enabling digital signing and , thereby ensuring sender authenticity, message integrity, and . These certificates bind a public key to an individual's , allowing recipients to verify the sender's identity and detect any tampering, while also facilitating that protects content from interception during transit. The primary standard governing email certificates is Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0, as defined in RFC 8551, which specifies conventions for X.509 certificate usage in email security. S/MIME leverages X.509 v3 certificates with specific extensions, including key usage bits for digital signature (to support signing and non-repudiation) and key encipherment (for encryption), as well as the extended key usage OID 1.3.6.1.5.5.7.3.4 (id-kp-emailProtection) to indicate suitability for email protection. Non-repudiation is achieved through the digital signature bit, preventing the signer from denying their action, while encryption relies on the recipient's public key to wrap symmetric session keys. Key characteristics of email certificates include the mandatory inclusion of the user's in the Subject Alternative Name (SAN) extension as an rfc822Name, ensuring the certificate is explicitly tied to the mailbox for validation during processing. These certificates can be issued by trusted Certificate Authorities (CAs) for broad interoperability or self-generated for personal or testing purposes, though self-signed ones require manual trust establishment by recipients. In messages, the signer's certificate and its chain are embedded within the structure of the (typically in the signed-data content type), allowing receiving clients to validate the chain against trusted roots without relying solely on external stores. Integration of email certificates occurs seamlessly in popular email clients such as Microsoft Outlook and Mozilla Thunderbird, where users import the certificate (often in PKCS#12 format) into the client's certificate store or the underlying operating system keychain. In Outlook, configuration involves navigating to Trust Center settings under Email Security to select the certificate for signing and encryption, enabling automatic handling of incoming signed or encrypted messages. Thunderbird supports S/MIME through its built-in certificate manager, where imported certificates are selected via account preferences, and the client processes attached certificate chains to verify signatures and decrypt content using the user's private key. This setup ensures that email clients can enforce S/MIME protections transparently during composition and receipt.

Self-Signed and Root Certificates

A is a public key certificate in which the and subject fields identify the same , and the certificate is digitally signed using the private key associated with that 's public key. This structure distinguishes it from certificates issued by a separate (CA), as no external verifies or endorses the binding of the public key to the claimed identity. In practice, self-signed certificates find application in controlled environments where formal trust validation is unnecessary or impractical, such as software development and testing setups, internal corporate networks, or bootstrapping initial PKI deployments. For instance, developers often generate self-signed certificates to simulate secure connections in local testing without incurring costs or delays from CA involvement. However, their use introduces security risks, including the lack of third-party identity verification, which can enable man-in-the-middle attacks if the certificate is not explicitly added to the relying party's trust store. Root certificates represent a specialized form of , serving as the foundational trust anchors in (PKI) hierarchies. Issued by highly trusted CAs, these certificates sit at the apex of certification chains and are inherently self-signed to establish the root of trust without dependency on higher authorities. In the hierarchical PKI model outlined in RFC 5280, validation of an end-entity certificate involves constructing a path that chains backward through intermediate CA certificates to a trusted root, ensuring each link's authenticity via signature verification against the issuer's public key. Root certificates are pre-installed in operating system and browser trust stores—such as the Mozilla Root Store, which enforces strict inclusion policies based on audits and compliance—to enable widespread reliance on the PKI ecosystem. The trust model relies on this chain to propagate assurance from the downward, but self-signed certificates must be meticulously managed to maintain integrity; any compromise undermines the entire . practices include periodic renewal of certificates, often planned years in advance to avoid expiration disruptions, and adherence to programs that govern inclusion, auditing, and in trust stores. For example, programs like Mozilla's require CAs to demonstrate ongoing operational and transparency for sustained trust.

Certificates with Subject Alternative Names

The Subject Alternative Name (SAN) extension in X.509 public key certificates enables the binding of multiple distinct identities to the certificate's subject, supplementing the primary Subject Distinguished Name (DN). This extension, defined in RFC 5280, permits the inclusion of various name types such as DNS names (via dNSName), IP addresses (via iPAddress), email addresses (via rfc822Name), uniform resource identifiers (URIs via uniformResourceIdentifier), and other general names like directory names or registered IDs. When present, the SAN extension is typically marked as critical if the Subject field lacks sufficient identifying , ensuring relying parties verify the alternative names rather than solely the Subject DN. SAN certificates are commonly employed in scenarios requiring flexible identity coverage, such as multi-domain hosting where a single certificate secures multiple distinct domains or subdomains without separate issuances. For instance, organizations operating load balancers or content delivery networks use SANs to associate one certificate with various hostnames, streamlining management across distributed services. In mobile application development, SANs facilitate identity matching for apps connecting to backend services via multiple endpoints, including IP addresses or URIs, enhancing without certificate proliferation. In TLS implementations, the SAN extension is essential for supporting , where a single serves multiple secure websites; during the TLS , clients match the requested against the certificate's SAN entries (often in conjunction with ) to validate the server's identity. Certificate authorities (CAs) issuing SAN-enabled certificates must validate ownership or control over each alternative name through methods like domain validation (e.g., HTTP-01 or DNS-01 challenges), ensuring the subject legitimately controls all listed identities to prevent unauthorized use. Despite their utility, SAN certificates introduce complexities in issuance, as CAs must perform independent validations for each name, potentially increasing processing time and costs compared to single-name certificates. Misconfigurations, such as omitting a required SAN or including invalid entries, can lead to handshake failures or security vulnerabilities, like unintended exposure of services. Additionally, practical limits on the number of SANs—often capped at 100 by major CAs—arise from certificate size constraints, as excessive entries inflate the certificate's payload and impact TLS performance.

Wildcard Certificates

A wildcard public key certificate incorporates an asterisk (*) as a wildcard character in the leftmost label of the within the (CN) field or, more commonly in modern practice, the Subject Alternative Name (SAN) extension, such as *.example.com. This configuration authenticates and secures the specified domain along with an unlimited number of its first-level subdomains—for instance, www.example.com or mail.example.com—while excluding the apex domain () unless explicitly listed and preventing coverage of deeper nested subdomains like sub.sub.example.com. The primary advantages of wildcard certificates lie in their cost-effectiveness and operational efficiency for environments with numerous or dynamically generated subdomains, as a single certificate eliminates the need for individual issuances per , thereby simplifying management and reducing expenses associated with procurement and renewal. Additionally, support for wildcard matching has been integral to TLS since its early standardization, with RFC 2818 (2000) explicitly defining the wildcard as matching any single component in the leftmost position during server identity verification. However, wildcard certificates have notable limitations, including restriction to single-level subdomain coverage only, as multi-level wildcards (e.g., *.sub.) remain prohibited under the CA/Browser Forum's Baseline Requirements to maintain precise identity verification and prevent overly broad scopes. This design also exposes them to heightened risks in subdomain takeover attacks, where an attacker exploits dangling DNS records for unused to host malicious content that benefits from the wildcard's valid TLS , potentially evading detection by users or monitoring tools. In practice, platforms frequently issue wildcard certificates to protect expansive structures, such as securing shop., api., and checkout. under a single *.example.com credential to support scalable online operations without repeated certificate deployments. Best practices for enhanced security involve combining wildcard entries with explicit SAN listings for high-value or static subdomains, allowing targeted protections while leveraging the wildcard for the rest, as this hybrid approach balances flexibility with granular control over certificate usage.

Other Specialized Certificates

Code signing certificates are used to authenticate software executables and ensure their integrity against tampering. These certificates bind a developer's or publisher's identity to the code, allowing operating systems and platforms to verify that the software has not been altered since signing. For instance, Extended Validation (EV) code signing certificates, governed by the CA/B Forum's guidelines, require rigorous identity verification and hardware-based private key storage to enhance trust in high-value software distribution. They are commonly employed in systems like Windows Authenticode for executable validation and Apple's notarization process to prevent distribution. Device and Internet of Things (IoT) certificates provide secure identity for embedded systems, often featuring short validity periods or device-specific binding to limit exposure in constrained environments. Enrollment for these certificates typically uses protocols like Enrollment over Secure Transport (EST), defined in RFC 7030, which automates certificate issuance and renewal over secure channels without manual intervention. EST supports initial bootstrapping for resource-limited devices, enabling scalable PKI management in IoT deployments such as smart sensors or industrial controllers. Timestamping certificates, issued by Time Stamping Authorities (TSAs), embed a trusted time reference into digital signatures to prove that data existed at a specific point in time, ensuring long-term validity even after the signing certificate expires. These certificates use key usage extensions to restrict operations to timestamping, preventing misuse in other cryptographic functions. In PKI, they are essential for legal and archival purposes, such as validating electronic contracts or software binaries against future disputes. Mobile operator certificates facilitate authentication in networks, leveraging PKI to secure user identity and network access. These certificates, often integrated into SIM applets, enable strong authentication for services like mobile payments or provisioning, as outlined in standards for wireless PKI (wPKI). By binding public keys to subscriber profiles, they support in ecosystems without relying on traditional passwords. As of 2025, emerging quantum-resistant certificates incorporate post-quantum algorithms to withstand attacks from quantum computers, addressing vulnerabilities in classical public key systems. The National Institute of Standards and Technology (NIST) has standardized CRYSTALS-Kyber (renamed ML-KEM) for key encapsulation in these certificates, enabling secure in PKI infrastructures. Adoption is advancing through frameworks like the Commercial National Security Algorithm Suite 2.0, which mandates quantum-resistant options for federal systems by 2035.

Issuance and Management

Certificate Authorities

A certificate authority (CA) is a that issues, signs, and manages digital certificates to verify the identity of entities such as websites, organizations, and individuals in (PKI). These organizations act as guarantors of the authenticity of public keys by digitally signing certificates, enabling secure communications over networks like the . CAs operate within hierarchical structures, consisting of CAs at the top level, which are self-signed and anchor trust, and intermediate or subordinate CAs that derive authority from CAs to issue end-entity certificates. The primary functions of a CA include vetting applicants through identity validation processes to ensure the requester's legitimacy before issuance, digitally signing the certificate with the CA's private key to bind the public key to the subject's identity, and maintaining detailed audit logs of all operations to support accountability and compliance. While CAs typically do not generate key pairs for applicants—leaving that to the entity—some services offer this as an optional feature to enhance . These functions ensure that certificates can be relied upon for , , and in applications like secure web browsing and signing. CAs are categorized into several types based on their scope and trust model: public CAs, which issue certificates trusted by default in web browsers and operating systems for broad internet use, exemplified by providers like and ; private CAs, deployed within enterprises for internal networks and not inherently trusted externally, such as Microsoft's Certificate Services; and automated free public CAs like , which streamline issuance for domain-validated certificates without manual vetting. Public CAs undergo rigorous accreditation to maintain global trust, while private CAs offer customized control for organizational needs. Legally, CAs bear liability for mis-issuance, where failure to properly validate an applicant can lead to financial and reputational damages, potentially resulting in lawsuits or regulatory penalties if certificates enable or breaches. To mitigate risks and demonstrate reliability, CAs must comply with independent audits such as WebTrust for Certification Authorities, a standard developed by the American Institute of CPAs and the that verifies adherence to principles like , certificate issuance, and operational controls. These audits, conducted annually, ensure CAs follow their published certificate policies and practices, fostering trust in the PKI ecosystem.

Root Certificate Programs

Root certificate programs are initiatives managed by major browser and operating system vendors to curate and maintain the set of trusted root certificates included in their software trust stores, thereby establishing a foundation for global (PKI) trust. These programs ensure that only reliable certificate authorities (CAs) can issue certificates that devices and applications automatically trust for secure connections, such as TLS/SSL for websites. Prominent examples include the Microsoft Trusted Root Certificate Program, which distributes roots to Windows operating systems; the Apple Root Certificate Program, which governs inclusions in , macOS, and ; and the Mozilla CA Certificate Program, which handles roots for and related software. Inclusion in these programs follows strict criteria to mitigate risks, including rigorous independent audits conducted annually under standards like WebTrust for CAs or ETSI TS 119 403. Root certificates must use sufficiently strong cryptographic keys, such as RSA keys of at least 2048 bits or equivalent (e.g., P-256 or higher), and CAs must demonstrate no history of significant breaches or policy violations. Programs conduct ongoing reviews, with potential for removal if compliance lapses occur; for instance, Symantec's root certificates were delisted from major browser trust stores in 2019 following repeated issuance errors and audit failures identified in prior years. The inclusion process typically begins with CA applications submitted to program operators, often via public bug trackers or dedicated portals, accompanied by detailed documentation on operations and security practices. Transparency is enforced through public reports, such as those in the Common CA Database (CCADB), and community governance involving expert reviewers who evaluate submissions. Once included, these roots enable worldwide trust chains, allowing billions of devices to verify certificates without manual intervention, though inclusions can take months to years due to scrutiny. , for example, uses a module owner and peer reviewers to deliberate on requests, ensuring broad input from the security community. As of 2025, programs have placed increased emphasis on (PQC) readiness to counter emerging threats, with some initiating pilots for hybrid or fully post-quantum roots using algorithms like ML-DSA-87. This aligns with broader industry shifts, including the CA/Browser Forum's baseline requirements limiting end-entity certificate validity to a maximum of 398 days to enhance agility in cryptographic transitions. These updates aim to future-proof the PKI ecosystem against algorithm vulnerabilities while maintaining compatibility.

Validation Processes

Public key certificates are issued by Certificate Authorities (CAs) only after performing identity verification to different levels of assurance, ensuring that the applicant controls the domain or represents a legitimate organization. These validation processes are standardized to balance security, usability, and operational feasibility, with requirements evolving to address emerging threats. The primary levels—Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV)—determine the information included in the certificate and the rigor of pre-issuance checks. Domain Validation (DV) provides the lowest level of assurance by confirming the applicant's control over the without verifying organizational identity. CAs perform this through automated or simple methods, such as sending an to administrative addresses associated with the domain (e.g., admin@), requiring the applicant to host a specific on an HTTP server accessible via the domain, or adding a to the domain's DNS. These challenges prove domain control quickly, often within minutes, making DV suitable for free or low-cost certificates used in basic . However, DV offers limited trust, as it does not prevent or impersonation by unauthorized parties. Organization Validation (OV) builds on DV by additionally confirming the existence and details of the legal entity behind the domain, providing moderate assurance for business use. CAs verify the organization's name, address, and registration through public databases (e.g., government business registries or records), third-party data sources, or direct phone contact with the applicant to corroborate details. If validated, the certificate includes the organization's verified name in the subject field, distinguishing it from anonymous DV certificates. This process typically takes days and involves manual review, ensuring the entity is legitimate but not deeply vetting operational or . OV is common for enterprise websites requiring some identity assurance without the overhead of higher levels. Extended Validation (EV) offers the highest assurance through comprehensive identity proofing, suitable for high-risk applications like . CAs conduct thorough checks, including confirming the organization's legal formation and standing via official records or legal opinions, verifying physical operational existence (e.g., through site visits or bills), and authenticating the identity of a responsible via government-issued photo ID, often with in-person or video verification. Additional steps may involve phone confirmation with the organization's and review of business incorporation documents. EV certificates include detailed, verified attributes in the subject field, such as the full and . Historically, EV certificates triggered a prominent "green bar" in browser address bars to signal high trust, but this visual indicator was phased out by major browsers starting in and removed by 2020–2021 in favor of subtler cues like company name display in the bar. The process can take weeks due to its rigor, emphasizing prevention of sophisticated . These validation levels are governed by the CA/Browser Forum's Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (version 2.1.9, effective November 2025), which mandate minimum practices for all publicly trusted TLS certificates, including prohibitions on certain outdated methods like email to domain contact for DV effective July 15, 2025. The requirements also cap data reuse periods for domain and IP validations at 398 days (reducing to 200 days by March 2026). For EV specifically, separate Guidelines (version 2.0.1, May 2024) outline enhanced proofing to ensure robust identity assurance. Compliance with these standards is audited annually, with non-conforming CAs risking removal from browser trust stores.

Revocation Mechanisms

Public key certificates can be invalidated before their expiration date through mechanisms to mitigate risks such as key compromise, cessation of operation, or errors in issuance. These mechanisms ensure that relying parties can verify the current validity of a certificate beyond its notBefore and notAfter dates. Certificate Revocation Lists (CRLs) are a primary mechanism where the issuing (CA) periodically publishes a digitally signed containing the serial numbers of revoked certificates, along with the revocation date and reason code. CRLs are distributed via HTTP or LDAP and include a nextUpdate field indicating when the next list will be available, allowing clients to cache them for efficiency. However, CRLs suffer from drawbacks such as download latency due to their growing size in high-volume PKIs and the potential for outdated information between updates. The (OCSP) addresses some CRL limitations by enabling real-time queries from clients to an OCSP responder operated by or on behalf of the CA, returning the status of a specific certificate as good, revoked, or unknown. OCSP responses are signed and include a thisUpdate and nextUpdate for caching, reducing the need for frequent queries. In TLS contexts, allows servers to include a pre-fetched OCSP response in the TLS , enhancing by avoiding direct client-to-CA connections that could reveal browsing habits. Additional methods enhance revocation reliability and monitoring. The OCSP Must-Staple extension, defined in the TLS Feature extension, mandates that servers provide stapled OCSP responses during TLS handshakes, enforcing checks and preventing deployment without status information. (CT) complements by requiring public logging of certificates in append-only, verifiable logs, enabling external monitoring for misissuances or unauthorized through proofs. Short-lived certificates, with validity periods as brief as days, reduce the overall need for by naturally expiring compromised keys quickly, and standards now permit skipping checks for certificates shorter than typical OCSP response lifetimes. Revocation mechanisms face challenges in balancing timeliness, , and ; for instance, CRL size can strain bandwidth in large-scale deployments, while OCSP queries introduce latency and potential single points of failure at responders. As of 2025, trends emphasize automation through protocols like ACME, which supports programmatic requests alongside issuance and renewal, minimizing manual intervention and enabling rapid response to incidents.

Applications and Security

Use in Website Security

Public key certificates are important for websites as they enable the HTTPS protocol, secure data transmission through encryption, build user trust via server authentication, and prevent browser security warnings that arise from missing or invalid certificates. They play a central role in website security by enabling , the secure version of HTTP that uses (TLS) to encrypt communications between browsers and servers. The certificate binds a public key to a , allowing clients to verify the server's identity and establish an encrypted channel that protects against and tampering during data transmission, such as login credentials or details. Without a valid certificate, connections default to unencrypted HTTP, exposing traffic to interception. To enforce HTTPS usage, websites implement HTTP Strict Transport Security (HSTS) via a response header that instructs browsers to redirect all future requests to the secure protocol for a defined duration, often up to six months. This mechanism relies on the presence of a trusted public key certificate to prevent protocol downgrade attacks, where adversaries attempt to force a shift to HTTP. HSTS preloading further embeds these policies in browser lists, ensuring automatic enforcement even on first visits. Browsers provide visual feedback through indicators like the padlock icon in the , which appears only for connections secured by a valid public key certificate, signaling both and authenticated identity. Conversely, missing, expired, or invalid certificates trigger prominent warnings, such as "Your connection is not private," to deter users from proceeding and highlight potential risks. Bypassing these warnings is not safe, as it disables server authentication, exposing users to man-in-the-middle attacks where an attacker could impersonate the legitimate site and intercept or steal personal data; users are strongly advised against proceeding, especially for unknown or temporary domains. Extended Validation (EV) certificates, which undergo rigorous organizational vetting, historically aimed to enhance trust with distinct indicators like green s; however, by 2020, major browsers including Chrome and removed these visuals due to evidence of negligible impact on user caution, resulting in diminished reliance on EV for perceptual security by 2025. Effective management incorporates best practices such as (CT), where certificate authorities append issued certificates to public, append-only logs for real-time auditing and detection of mis-issuance, enabling domain owners to monitor and revoke unauthorized ones promptly. Automation via tools like ACME protocol clients ensures timely renewals, often every 90 days, to prevent lapses that could expose sites to attacks. Servers must also configure full certificate chain validation, delivering intermediate certificates alongside the leaf to allow browsers to trace trust back to a root authority without errors. These practices have driven significant adoption, with Google's Transparency Report indicating that over 95% of web pages loaded in Chrome are now served over as of June 2025, up from less than 50% a decade earlier, underscoring the scalability of public key certificates in bolstering global web security.

Regulatory Usage in the European Union

The Regulation, formally Regulation (EU) No 910/2014, establishes a comprehensive framework for and trust services across the , mandating the use of qualified public key certificates for advanced electronic signatures and seals to ensure their legal equivalence to handwritten signatures in cross-border transactions. It defines a of certification authorities, distinguishing between basic trust service providers for standard electronic signatures and qualified trust service providers (QTSPs) that issue qualified certificates meeting stringent security and audit requirements, such as the use of secure signature-creation devices. These qualified certificates bind the public key to the identity of the signer or seal creator through verified processes, enabling reliable in electronic transactions. In 2024, the eIDAS Regulation was updated through the European Digital Identity Regulation (eIDAS 2.0), which entered into force on May 20, 2024, enhancing qualified trust services by introducing new categories like attribute attestation and electronic archiving while reinforcing the role of qualified certificates in securing digital identities. This update expands applications to mandatory electronic identification for public and private services, including cross-border recognition of national eID schemes, and integrates with data protection under the GDPR by requiring qualified certificates for encrypted secure data transfers to prevent unauthorized access during processing and transmission. For instance, Article 32 of the GDPR emphasizes encryption of personal data, where public key infrastructure supported by eIDAS-qualified certificates ensures confidentiality in transfers. The European Telecommunications Standards Institute (ETSI) supports implementation through EN 319 411, which specifies profiles for qualified certificates, including requirements for key usage, validity periods, and extensions to ensure and security in trust services. Supervision occurs via national competent bodies that accredit QTSPs, with compliance verified through Trusted Lists—publicly maintained registries of qualified providers and their services, updated dynamically to reflect revocations or changes in certificate status. These lists enable automated validation of certificate chains across member states, fostering trust in cross-border electronic services. By 2025, 2.0 developments emphasize integration of qualified public key certificates with European Digital Identity Wallets, which allow users to store and selectively share certified attributes for without full disclosure, with mandatory acceptance by entities by 2026 and private sectors by 2027. Post-Brexit alignments maintain partial interoperability for UK-EU certificate recognition under retained frameworks, though full cross-border equivalence requires bilateral agreements to align QTSP supervision.

Comparison to Unsecured Connections

Unsecured connections, such as those using plain HTTP, expose transmitted data to significant risks including , injection attacks, and theft. Attackers can eavesdrop on unencrypted traffic, particularly on public networks, to capture sensitive information like credentials or personal details without detection. This vulnerability also enables man-in-the-middle (MITM) attacks, where malicious actors and potentially alter data in transit, compromising both and . Public key certificates mitigate these threats by facilitating secure protocols like , which ensure confidentiality through end-to-end encryption of data in transit, rendering intercepted information unreadable to unauthorized parties. They provide integrity via digital signatures that verify data has not been tampered with during transmission. Additionally, certificates enable authentication by binding public keys to verified identities through trusted certificate authorities, preventing server impersonation and reducing the feasibility of MITM attacks. Despite these benefits, public key certificates introduce performance trade-offs, notably the computational and latency overhead of the initial , which requires multiple round trips to negotiate parameters and can delay connection establishment by 100-200 milliseconds on average. This is largely addressed through session resumption mechanisms, such as session tickets or identifiers, which allow clients to reuse prior session keys for subsequent connections, cutting time by up to 50% and minimizing repeated full negotiations. Adoption challenges persist in legacy systems, where outdated often lacks compatibility with modern TLS versions, necessitating costly upgrades or intermediary proxies to enable certificate-based security. By November 2025, has achieved near-universal adoption, with over 95% of global page loads occurring over encrypted connections, dramatically elevating baseline web security. Protocols built on , such as , build on this foundation by integrating TLS encryption directly into the , reducing and connection setup latency by up to 33% compared to traditional over TCP, thereby enhancing performance without sacrificing security.

Standards and Limitations

Governing Standards

The primary international standard governing the format and framework for public key certificates is ITU-T Recommendation , which defines the structure for public-key and attribute certificates within the Open Systems Interconnection (OSI) Directory framework. The latest version, (10/2019) with Amendment 1 (10/2024), specifies the core certificate format including mandatory fields such as subject name, public key information, issuer details, validity period, and signature algorithm, while supporting version 3 extensions for additional attributes like key usage, subject alternative names, and certificate policies to enhance flexibility in (PKI) applications. Attribute certificates, as outlined in the standard, provide a mechanism to bind authorization attributes to an identity without altering the public key certificate, enabling privilege management infrastructures separate from authentication. Several Internet Engineering Task Force (IETF) Request for Comments (RFCs) profile and extend X.509 for specific Internet protocols and use cases. RFC 5280 (2008) establishes the Internet X.509 PKI Certificate and Certificate Revocation List (CRL) Profile, mandating the use of X.509 version 3 certificates and version 2 CRLs with required extensions for path validation, name constraints, and basic constraints to ensure interoperability in Internet PKI deployments. For secure email, RFC 8551 (2019) defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0, specifying certificate handling conventions that align with X.509 for signing and encrypting MIME data, including support for multi-purpose Internet mail extensions in certificate extensions. Certificate Transparency is addressed in RFC 9162 (2021), which defines Version 2.0 of the append-only log protocol to publicly record TLS certificate issuances, requiring monitors and auditors to verify log consistency via Merkle tree proofs for detecting mis-issuances. Additionally, RFC 8446 (2018) specifies TLS version 1.3, incorporating X.509 certificate profiles for server authentication and key exchange, with requirements for certificate chains, signature algorithms, and extensions to support secure handshakes over the Internet. The , a collaborative body of certificate authorities and browser vendors, issues the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, which outline minimum criteria for identity validation, lifecycle management, auditing, and issuance practices to maintain trust in web PKI. The latest version, 2.1.9 (November 2025), includes updates to address emerging security needs, such as shortened certificate lifetimes and enhanced validation for domain control, while ongoing discussions incorporate considerations for to mitigate future threats from . Complementing this, the Forum's Extended Validation (EV) Guidelines (version 2.0.1, May 2024) define rigorous identity verification processes for EV certificates, requiring legal entity authentication, operational existence checks, and physical address confirmation to provide higher assurance for sensitive applications like financial transactions. Other standards support certificate-related operations and regional requirements. RFC 5652 (2009) describes the (CMS), an evolution of , for encapsulating signed, enveloped, or digested data using certificates, enabling secure messaging with detached signatures and multiple signer support. For European Union-qualified certificates under regulations, ETSI TS 119 312 (version 1.5.1, December 2024) specifies cryptographic suites, including approved algorithms, key lengths, and hash functions for creating and validating qualified digital signatures, seals, and timestamps to ensure compliance with trust service provider requirements.

Known Weaknesses and Limitations

Public key certificates rely on cryptographic algorithms that have faced significant weaknesses over time. The hashing algorithm, once widely used for signing certificates, was deprecated due to its vulnerability to collision attacks, with major browsers ceasing acceptance of SHA-1-signed certificates by early 2017. Similarly, the algorithm proved susceptible to practical collision attacks, enabling attackers to forge certificates by generating identical hashes for malicious and legitimate data, as demonstrated in 2008 when researchers created rogue certificates for high-profile domains. These flaws underscored the need to transition to stronger hashes like SHA-256. A more pressing long-term threat stems from , which could break widely used asymmetric algorithms such as RSA and ECC through algorithms like Shor's, potentially allowing decryption of private keys from public certificates. In response, the National Institute of Standards and Technology (NIST) selected and standardized (PQC) algorithms in 2024, including ML-KEM for key encapsulation and ML-DSA for digital signatures, urging migration to hybrid or fully PQC-based certificates to mitigate these risks. Certificate authorities (CAs) represent single points of failure in the , as a compromise of a root CA can undermine trust in all issued certificates. The 2011 DigiNotar breach exemplified this, where intruders hacked the Dutch CA's systems, issuing over 500 fraudulent certificates for domains like google.com, enabling man-in-the-middle attacks primarily targeting Iranian users. This incident led to the revocation of 's root certificates from major browser trust stores, highlighting the systemic risk of centralized CA reliance. Operational limitations further exacerbate vulnerabilities in certificate systems. Long validity periods, often up to two years, prolong exposure if a private key is compromised or a certificate is misissued, delaying detection and . The 2011 Comodo incident illustrated misissuance risks, where a compromised led to nine fraudulent certificates for sites including login.yahoo.com and mail.google.com, issued without proper validation. To address these issues, several mitigations have been adopted. Shorter certificate lifetimes, reduced from 825 days to a maximum of 47 days by March 15, 2029 via ballot (with interim reductions: 398 days until March 15, 2026; 200 days from March 15, 2026 to March 15, 2027; 100 days from March 15, 2027 to March 15, 2029), limit the window of vulnerability and encourage automated renewal practices. (CT) logging requires public appending of certificates to auditable, append-only logs, enabling early detection of misissuance through independent monitoring; note that Version 1.0 logs (per RFC 6962) will become read-only on November 30, 2025, and shut down on February 28, 2026, with operations migrating to (RFC 9162). Promoting multi-CA diversity, where systems trust multiple independent authorities rather than a single root, reduces the impact of any one compromise, though implementation varies across infrastructures. Despite these measures, ongoing challenges persist, such as wildcard certificates' risks to subdomains, where a single private key compromise exposes all covered s to attacks like subdomain takeovers or .

References

  1. https://csrc.nist.gov/glossary/term/x_509_public_key_certificate
  2. https://datatracker.ietf.org/doc/html/rfc5280#section-4.1
  3. https://csrc.nist.gov/glossary/term/certificate_authority
  4. https://datatracker.ietf.org/doc/html/rfc5280#section-3.3
  5. https://www.cyber.gc.ca/en/guidance/guidance-securely-configuring-network-protocols-itsp40062
  6. https://www.idmanagement.gov/university/pki/
  7. https://datatracker.ietf.org/doc/html/rfc5280
  8. https://csrc.nist.gov/glossary/term/public_key_certificate
  9. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-32.pdf
  10. https://csrc.nist.gov/glossary/term/public_key_infrastructure
  11. https://ee.stanford.edu/~hellman/publications/24.pdf
  12. https://datatracker.ietf.org/doc/html/rfc4556
  13. https://www.openpgp.org/about/history/
  14. https://www.thesslstore.com/blog/ssl-and-tls-versions-celebrating-30-years-of-history/
  15. https://www.digicert.com/blog/evolution-of-ssl
  16. https://cabforum.org/2013/09/02/welcome-to-the-ca/browser-forum/
  17. https://datatracker.ietf.org/doc/html/rfc8555
  18. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
  19. https://csrc.nist.gov/projects/post-quantum-cryptography
  20. https://techcommunity.microsoft.com/blog/microsoft-security-blog/post-quantum-cryptography-apis-now-generally-available-on-microsoft-platforms/4469093
  21. https://datatracker.ietf.org/doc/html/rfc7468
  22. https://www.cloudflare.com/learning/ssl/how-does-ssl-work/
  23. https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2
  24. https://www.digicert.com/how-tls-ssl-certificates-work
  25. https://www.digicert.com/faq/public-trust-and-certificates/what-is-a-multi-domain-san-certificate
  26. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-16.pdf
  27. https://cabforum.org/working-groups/server/baseline-requirements/requirements/
  28. https://datatracker.ietf.org/doc/html/rfc8446#section-1.3
  29. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/securing_networks/creating-and-managing-tls-keys-and-certificates_securing-networks
  30. https://www.portnox.com/cybersecurity-101/server-certificate/
  31. https://datatracker.ietf.org/doc/html/rfc8446
  32. https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/
  33. https://www.ssl.com/article/authenticating-users-and-iot-devices-with-mutual-tls/
  34. https://learn.microsoft.com/en-us/windows/security/identity-protection/smart-cards/smart-card-certificate-requirements-and-enumeration
  35. https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.6
  36. https://datatracker.ietf.org/doc/html/rfc8446#section-4.3.2
  37. https://datatracker.ietf.org/doc/html/rfc8551
  38. https://www.digicert.com/faq/email-trust/what-is-smime-or-encrypted-email
  39. https://cabforum.org/working-groups/smime/requirements/
  40. https://datatracker.ietf.org/doc/html/rfc2632
  41. https://support.microsoft.com/en-us/office/set-up-outlook-to-use-s-mime-encryption-2e57e4bd-4cc2-4531-9a39-426e7c873e26
  42. https://www.ssl.com/how-to/installing-an-s-mime-certificate-and-sending-secure-email-in-mozilla-thunderbird-on-windows-10/
  43. https://www.keyfactor.com/blog/self-signed-certificate-risks/
  44. https://www.encryptionconsulting.com/education-center/self-signed-certificates/
  45. https://www.securew2.com/blog/the-dangers-of-self-signed-certificates
  46. https://www.keyfactor.com/blog/what-types-of-certificates-can-i-self-sign-and-should-i-really/
  47. https://www.digicert.com/what-is-pki
  48. https://datatracker.ietf.org/doc/html/rfc5280#section-6
  49. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
  50. https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/renew-root-ca-certificate
  51. https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6
  52. https://www.ssl.com/article/the-essential-guide-to-multi-domain-ucc-san-certificates/
  53. https://www.sectigo.com/knowledge-base/detail/Subject-Alternative-Name-SAN-1527076087222/kA01N000000zFKm
  54. https://www.digicert.com/faq/public-trust-and-certificates/what-is-a-wildcard-certificate
  55. https://www.ssl.com/article/what-is-a-wildcard-ssl-certificate/
  56. https://datatracker.ietf.org/doc/html/rfc6125
  57. https://www.keyfactor.com/blog/what-is-a-wildcard-certificate/
  58. https://knowledge.digicert.com/quovadis/ssl-certificates/ssl-general-topics/what-are-the-pros-and-cons-of-a-wildcard-certificate
  59. https://www.packetlabs.net/posts/wildcard-certificates/
  60. https://www.namesilo.com/blog/en/dns/wildcard-domains-innovation-vs-security-in-modern-dns-management
  61. https://comodosslstore.com/resources/wildcard-certificate-examples/
  62. https://comodosslstore.com/resources/san-vs-wildcard-ssl-certificate-whats-the-difference/
  63. https://cabforum.org/working-groups/code-signing/ev-code-signing-certificate-guidelines/
  64. https://cabforum.org/uploads/Baseline-Requirements-for-the-Issuance-and-Management-of-Code-Signing.v3.7.pdf
  65. https://datatracker.ietf.org/doc/html/rfc7030
  66. https://docs.digicert.com/en/device-trust-manager/get-started/concepts/enrollment-over-secure-transport--est-.html
  67. https://www.digicert.com/blog/best-practices-timestamping
  68. https://www.gsma.com/solutions-and-impact/technologies/mobile-identity/wp-content/uploads/2022/12/IDY.25-Mobile-Connect-Authorise-PKI-Definition-and-Technical-Requirements-v1.0.docx
  69. https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
  70. https://www.techtarget.com/searchsecurity/definition/certificate-authority
  71. https://www.digicert.com/blog/what-is-a-certificate-authority
  72. https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certification-authority-role
  73. https://www.futurex.com/blog/what-is-a-certificate-authority-ca-and-how-does-it-work
  74. https://www.utimaco.com/service/knowledge-base/digital-signing/what-certificate-authority
  75. https://www.portnox.com/cybersecurity-101/certificate-authorities/
  76. https://www.sectigo.com/resource-library/understanding-the-different-types-of-certificate-authorities
  77. https://www.securew2.com/blog/public-vs-private-certificate-authority
  78. https://www.encryptionconsulting.com/education-center/types-of-ca/
  79. https://www.thesslstore.com/blog/what-is-a-certificate-authority-ca-and-what-do-they-do/
  80. https://www.digicert.com/webtrust-audits
  81. https://www.bdo.com/getmedia/28d80961-6650-4ad3-8f8f-f7aeccde018c/ASSR_TPA_Webtrust-for-Certification-Authorities_Insert_WEB.pdf?ext=.pdf
  82. https://learn.microsoft.com/en-us/security/trusted-root/
  83. https://www.apple.com/certificateauthority/ca_program.html
  84. https://learn.microsoft.com/en-us/security/trusted-root/program-requirements
  85. https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html
  86. https://wiki.mozilla.org/CA/Application_Process
  87. https://blog.cloudflare.com/pq-2025/
  88. https://cabforum.org/about/information/consumers/
  89. https://docs.digicert.com/en/certcentral/manage-certificates/domain-control-validation-methods.html
  90. https://www.digicert.com/faq/public-trust-and-certificates/what-are-the-validation-methods-for-tls-ssl-certificates
  91. https://cabforum.org/working-groups/server/extended-validation/documents/CA-Browser-Forum-EV-Guidelines-2.0.1.pdf
  92. https://www.ssltrust.com/blog/green-address-bar
  93. https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.1.9.pdf
  94. https://www.keyfactor.com/blog/what-is-a-certificate-revocation-list-crl-vs-ocsp/
  95. https://datatracker.ietf.org/doc/html/rfc6960
  96. https://datatracker.ietf.org/doc/html/rfc7633
  97. https://datatracker.ietf.org/doc/html/rfc6962
  98. https://cabforum.org/2023/07/14/ballot-sc063v4-make-ocsp-optional-require-crls-and-incentivize-automation/
  99. https://www.fastly.com/blog/addressing-challenges-tls-revocation-and-ocsp
  100. https://www.cloudflare.com/learning/ssl/what-is-https/
  101. https://developers.cloudflare.com/ssl/edge-certificates/additional-options/http-strict-transport-security/
  102. https://security.stackexchange.com/questions/213687/is-encryption-still-applied-if-you-ignore-the-ssl-certificate-warning-for-self-s
  103. https://support.mozilla.org/en-US/kb/how-do-i-tell-if-my-connection-is-secure
  104. https://www.ssldragon.com/blog/green-bar-ssl/
  105. https://transparencyreport.google.com/https/overview
  106. https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation
  107. https://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.06.01_60/en_31941102v020601p.pdf
  108. https://digital-strategy.ec.europa.eu/en/faqs/questions-answers-trust-services-under-european-digital-identity-regulation
  109. https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/rules-international-data-transfers_en
  110. https://digital-strategy.ec.europa.eu/en/policies/eu-trusted-lists
  111. https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/694487738/EU%2BDigital%2BIdentity%2BWallet%2BHome
  112. https://ico.org.uk/for-organisations/guide-to-eidas/what-is-the-eidas-regulation/
  113. https://www.cloudflare.com/learning/ssl/why-is-http-not-secure/
  114. https://owasp.org/www-project-mobile-top-10/2016-risks/m3-insecure-communication
  115. https://www.namesilo.com/blog/en/privacy-security/the-importance-of-ssl-certificates-for-website-security
  116. https://www.digicert.com/blog/lessons-from-the-equifax-data-breach
  117. https://hpbn.co/transport-layer-security-tls/
  118. https://www.sciencedirect.com/science/article/pii/S0740624X22001204
  119. https://transparencyreport.google.com/https
  120. https://www.cloudflare.com/learning/performance/what-is-http3/
  121. https://www.itu.int/rec/T-REC-X.509/en
  122. https://datatracker.ietf.org/doc/html/rfc9162
  123. https://datatracker.ietf.org/doc/html/rfc5652
  124. https://learn.microsoft.com/en-us/security-updates/securityadvisories/2017/4010323
  125. https://www.kb.cert.org/vuls/id/836068
  126. https://www.enisa.europa.eu/sites/default/files/all_files/Operation_Black_Tulip_v2.pdf
  127. https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days
  128. https://blog.mozilla.org/security/2011/03/25/comodo-certificate-issue-follow-up/
  129. https://certificate.transparency.dev/
  130. https://letsencrypt.org/2025/08/14/rfc-6962-logs-eol
  131. https://www.keyfactor.com/blog/decentralized-pki-the-new-reality/
  132. https://media.defense.gov/2021/Oct/07/2002869955/-1/-1/0/CSI_AVOID%2520DANGERS%2520OF%2520WILDCARD%2520TLS%2520CERTIFICATES%2520AND%2520THE%2520ALPACA%2520TECHNIQUE_211007.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.