brain initiation

20231019192337-certificate.org

@@ -0,0 +1,49 @@
+:PROPERTIES:
+:ID:       e28dfeaa-876b-4255-a25e-dcc0c909d08a
+:END:
+#+title:  certificate
+
+In cryptography, a public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner (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 ([[id:872ee33b-8361-40c7-9d88-69b3afe5ade2][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 ([[id:95c8982d-e104-43a2-9bb2-fd7e1c3204f2][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), 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) as defined in RFC 5280.
+
+* Types of Certificates
+** TLS/SSL server certificate
+The Transport Layer Security (TLS) [[id:bd5b34ba-aa98-4808-b97b-2376aa7b8866][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:
+
+- The subject of the certificate matches the hostname (not to be confused with the domain name) to which the [[id:70899526-8b7d-4976-94fc-cc07c41e550a][client]] is trying to connect.
+- 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. 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 [[id:f2b1d5af-1a7d-47a5-95c8-4a85d558419e][server]].
+
+Internet-facing servers, such as public web servers, must obtain their certificates from a trusted, public certificate authority (CA).
+
+** TLS/SSL client certificate
+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 [[id:fde35a08-897d-4502-aead-1f4414ea639c][packets]].
+
+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 ([[id:1af47b07-4205-46ac-837a-ee078067328a][vpn]]) and Remote Desktop Services, where they authenticate devices.
+
+** Email certificate
+In accordance with the S/[[id:d60f8060-4557-42d5-831d-b68bfb42df59][MIME]] [[id:bd5b34ba-aa98-4808-b97b-2376aa7b8866][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 and root certificates
+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.
+
+_Self-signed certificates have their own limited uses. They have full trust value when the issuer and the sole user are the same entity. For example, the Encrypting File System on Microsoft Windows issues a self-signed certificate on behalf of the encrypting user and uses it to transparently decrypt data on the fly. The digital certif_icate chain of trust starts with a self-signed certificate, called a root certificate, trust anchor, or trust [[id:673d1cb1-536b-42f1-a046-40a8937c4283][root]]. A certificate authority self-signs a root certificate to be able to sign other certificates._
+
+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 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.
+
+** other certificates
+- 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[5] 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."[6]
+- 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."