In cryptography, public key certificates, also known as digital certificates or identity certificates, are electronic documents used to prove ownership of a public key. This certificate includes information about the key, information about the identity of the owner (called the subject), and the digital signature of an entity that has verified the contents of the certificate (called the publisher). If the signature is valid, and the software that checks the certificate trusts the publisher, then it can use that key to communicate securely with the subject of the certificate. In email encryption, code signing, and electronic signature systems, the subject of a certificate is usually a person or organization. However, in Transport Layer Security (TLS), the subject of a certificate is usually a computer or other device, although TLS certificates can identify organizations or individuals other than their primary role in identifying devices. TLS, sometimes called by the older name Secure Sockets Layer (SSL), is famous for being part of HTTPS, the protocol for browsing the web safely.
In a public key infrastructure scheme (PKI), the issuer of the certificate is a certificate authority (CA), usually a company that charges customers to issue certificates for them. In contrast, in a network of trust schemes, individuals sign each key directly, in a format that performs a function similar to a public key certificate.
The most common format for public key certificates is determined by X.509. Since X.509 is very common, its format is more limited by the profile specified for certain use cases, such as Public Key Infrastructure (X.509) as defined in RFC 5280.
Video Public key certificate
Jenis sertifikat
sertifikat server TLS/SSL
In TLS (the latest replacement for SSL), the server is required to present the certificate as part of the initial connection settings. Clients connected to the server will perform the certification path validation algorithm:
- The subject of the certificate matches the hostname that the client is trying to connect to.
- The certificate is signed by a trusted certificate authority.
The primary hostname (website domain name) is listed as Public Name in the Subject field of the certificate. Certificates may apply to multiple hostnames (multiple websites). Such certificates are usually called Subject Alternative Name (SAN) Certificates or Integrated Communications Certificates (UCC) . This certificate contains the Alternate Name of the Field field, although many CAs will also place it into the General Names field for backward compatibility. If some hostnames contain an asterisk (*), the certificate may also be called wildcard certificate .
The TLS server can be configured with self-signed certificates. When that happens, the client generally will not be able to verify the certificate, and will stop the connection unless certificate checking is disabled.
TLS/SSL client certificates
Client certificates are less common than server certificates, and are used to authenticate clients connected to TLS services, for example to provide access control. Because most services provide access to individuals, not devices, most client certificates contain email addresses or personal names, not hostnames. Also, since authentication is usually managed by the service provider, client certificates are not normally issued by public CAs that provide server certificates. Conversely, service operators who require a client certificate will usually operate their own internal CA to publish it. Client certificates are supported by many web browsers, but most services use passwords and cookies to authenticate users, not client certificates.
Client certificates are more common in RPC systems, where they are used to authenticate devices to ensure that only authorized devices can make certain RPC calls.
Email certificate
In the S/MIME protocol for secure email, the sender needs to find which public key to use for the given recipient. They get this information from an email certificate. Some publicly licensed certificate authorities provide email certificates, but more commonly S/MIME is used when communicating within a particular organization, and the organization is running its own CA, trusted by participants in the email system.
Certificate signing code
Certificates can also be used to validate signatures on the program to ensure they are not tampered with during delivery.
Qualified certificates
Certificates that identify individuals, usually for the purpose of electronic signatures. It is most commonly used in Europe, where eIDAS rules standardize them and require their recognition.
The root certificate
Self signed certificate used to sign another certificate. Also sometimes called anchor of trust .
Medium certificate
The certificate used to sign another certificate. An intermediate certificate must be signed by another intermediary certificate, or a root certificate.
End-entity or leaf certificate
Any certificate that can not be used to sign another certificate. For example, TLS/SSL servers and client certificates, email certificates, certificate signing codes, and eligible certificates are all end-entity certificates.
Self-signed certificate
A certificate with a subject that matches the publisher, and a signature that can be verified by its own public key. Most types of certificates can be self-signed. Self-signed certificates are also often called snake oil certificates to emphasize their unbelief.
Maps Public key certificate
Common columns
These are some of the most common areas in the certificate. Most certificates contain a number of fields not listed here. Note that in the case of a X.509 certificate representation, the certificate is not "flat" but contains this field that is nested in the various structures in the certificate.
- Serial Number : Used to uniquely identify a certificate in a CA system. Specifically this is used to track revocation information.
- Subjects : Entities that have certificates: machines, individuals, or organizations.
- Publisher : The entity verifying the information and signing the certificate.
- Not Before : The earliest time and date in which the certificate is valid. Usually set to several hours or days before the certificate is issued, to avoid jam jams.
- Not After : The elapsed time and date are deprecated.
- Lock Usage : Valid use of cryptography from certificate public key. Common values ​​include digital signature validation, encryption keys, and certificate signing.
- Extended Lock Usage : Application where certificates can be used. Common values ​​include TLS server authentication, email protection, and code signing.
- Public Key : The public key belongs to the certificate subject.
- Signature Algorithm : The algorithm used to sign public key certificates.
- Signature : The signature of the certificate body by the publisher's private key.
Usage in European Union
In the European Union, electronic signatures on legal documents are usually done using a digital signature with an accompanying identity certificate. This is largely because the signatures are given the same enforceability as handwritten signatures under eIDAS, EU regulations.
In the X.509 trust model, the certificate authority (CA) is responsible for signing the certificate. This certificate acts as an introduction between two parties, which means that the CA acts as a trusted third party. CA processes requests from the person or organization requesting the certificate (called the customer), verifies the information, and potentially signs the final entity certificate based on that information. To perform this role effectively, CA must have one or more trusted root certificates or intermediate certificates and associated private keys. CA can achieve this widespread trust by having their root certificates included in popular software, or by obtaining cross signatures from other CAs that delegate trust. Other CAs are trusted in relatively small communities, such as businesses, and are distributed by other mechanisms such as Windows Group Policy.
The certificate authority is also responsible for keeping the latest revocation information about the certificates they have issued, indicating whether the certificate is valid. They provide this information through the Online Certificate Status Protocol (OCSP) and/or Certificate Revocation List (CRL).
The root program
Some major software lists certificate authorities that are trusted by default. This makes it easier for end users to validate certificates, and makes it easier for the person or organization that requests the certificate to know which certificate authority can issue certificates that will be widely trusted. This is very important in HTTPS, where website operators generally want to get a certificate that is trusted by almost all potential visitors to their website.
The policies and processes that providers use to decide which certificate authority to trust by their software are called root programs. The most influential root programs are:
- Microsoft Root Program
- Apple Root Program
- Mozilla Root Program
- Java root program Oracle
- Adobe AATL Adobe Approved Trust List and root program EUTL (used for signing documents)
Browsers other than Firefox generally use operating system facilities to decide which certificate authority is trusted. So, for example, Chrome on Windows trusts the certificate authority included in the Microsoft Root Program, while on macOS or iOS, Chrome trusts certificate authority in the Apple Root Program. Edge and Safari use their respective operating system trust stores as well, but each is only available on one OS. Firefox uses the Mozilla Root Program trust store on all platforms.
The Mozilla Root program is publicly operated, and the certificate list is part of Firefox's open source web browser, so it is widely used outside of Firefox. For example, while there is no common Linux Root Program, many Linux distributions, such as Debian, include packages that periodically copy Firefox's trust list, which is then used by the application.
The root program generally provides a set of valid destinations with the certificates they include. For example, some CAs may be trusted to issue a TLS server certificate, but not to code signing certificates. This is indicated by a set of trust bits in the root certificate storage system.
Certificate and website security
The most common use of certificates is for HTTPS-based websites. The web browser validates that the HTTPS web server is authentic, so users can feel secure that their interaction with the website does not have a lookout and that the website is what it claims to be. This security is important for electronic commerce. In practice, the website operator obtains the certificate by applying to the certificate authority with the certificate signing request. The certificate request is an electronic document that contains the name of the website, company information, and public key. The certificate provider signs the request, resulting in a public certificate. During web search, this public certificate is presented to any web browser that connects to the website and proves to the web browser that the service provider believes it has issued a certificate to the owner of that website.
For example, when a user connects to https://www.example.com/ with their browser, if the browser does not provide any certificate warning messages, then the user can theoretically believe that interacting with https://www.example.com/ is equivalent to interacting with an entity in contact with an email address registered with the public recorder under "example.com", even though that email address is not displayed anywhere on the website. There are no other guarantees implied. Furthermore, the relationship between certificate buyers, website operators, and website content generators may be tenuous and not guaranteed. At most, the certificate guarantees the uniqueness of the website, provided that the website itself has not been compromised (hacked) or the certificate issuance process.
The certificate provider may choose to issue three types of certificates, each requiring its own checkup tightness level. In order to increase their rigidity (and of course, cost) they are: Domain Validation, Organizational Validation and Extended Validation. This constancy is freely agreed upon by volunteers at the CA/Browser Forum.
Validation rate
Domain validation
The certificate provider will issue a Domain Validation (DV) class certificate to the buyer if the buyer can demonstrate one check criteria: the right to administratively manage the domain name.
Organization Validation
The certificate provider will issue the Validate Organization class certificate (OV) to the buyer if the buyer can meet two criteria: the right to administer administratively the domain name in question, and perhaps, the actual existence of the organization as a legal entity. The certificate provider issues the OV inspection criteria through its Certificate Policy.
Additional validation
To obtain an Extended Validation (EV) certificate, the buyer must induce the provider of its legal identity certificate, including manual verification checks by humans. Like the OV certificate, the certificate provider issues EV vetting criteria through its Certificate Policy.
Browsers will generally offer users a visual indication of legal identity when a site presents an EV certificate. Most browsers display an official name before the domain, and use bright green to highlight changes. In this way, the user can see the legal identity of the owner has been verified.
Weakness
The web browser will not alert users if the website suddenly presents a different certificate, even if the certificate has a lower number of key bits, even if it has a different provider, and even if the previous certificate has a long expiration date into the future. However a change from EV certificate to non-EV certificate will be visible because the green bar will no longer be displayed. If the certificate provider is under the jurisdiction of the government, the government may have the freedom to order the provider to produce any certificate, such as for law enforcement purposes. Providers of subsidiary wholesale certificates also have the freedom to produce any certificates.
All web browsers come with a complete list of trusted root certificates, many of which are controlled by organizations that may be unknown to users. Each of these organizations is free to issue any certificates for any website and has a guarantee that a web browser that includes its root certificate will accept it as genuine. In this case, the end user must rely on the browser software developer to manage the list of inherited certificates and the certificate provider to behave correctly and notify the browser developer of the problem certificate. Although rare, there are several incidents where fake certificates have been issued: in some cases, the browser has detected a fraud; in others, some time elapsed before the browser developers deleted this certificate from their software.
The list of default certificates is also not limited to that provided by the browser developer: users (and application degrees) are free to extend the list for special purposes like for corporate intranets. This means that if someone gains access to the machine and can install a new root certificate in the browser, the browser will recognize websites that use certificates entered as valid.
For verifiable security, reliance on something outside the system has the consequence that public key certification schemes must rely on some special regulatory assumptions, such as the existence of a certificate authority.
Usefulness of unsafe websites
Regardless of the limitations described above, TLS authenticated by certificates is deemed mandatory by all security guidelines whenever a website hosts confidential information or performs material transactions. This is because, in practice, regardless of the disadvantages described above, websites secured by public key certificates are still more secure than insecure http://websites.
Standard
The Computer Security Division of the National Institute of Standards and Technology (NIST) provides guidance documents for the Public Key Certificate:
- SP 800-32 Introduction to PKI Federal Public Key and Infrastructure Technology
- SP 800-25 Use of Federal Public Key Technology for Digital Signatures and Authentication
See also
- Authorization certificate
- Digital tax certificates or digital invoices or electronic invoices or electronic tax certificates
- Privacy is Good Enough
References
Source of the article : Wikipedia
0 Comments