-
Notifications
You must be signed in to change notification settings - Fork 0
/
Documentation.txt
113 lines (98 loc) · 14.6 KB
/
Documentation.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
X.509 is a standard that defines the structure of the certificate. X.509 uses a formal language called Abstract Syntax Notation One (ASN.1) to express the certificate's data structure.
The certificate in X.509 format includes the following information:
Version: The version number of the certificate data format as per X.509.
Serial number: Unique identifier of the certificate assigned by CA
Public Key: The owner's public key
Subject: This contains the Distinguished Name (DN) information for the certificate. The fields included in a typical certificate are: • Common Name (CN) • Organization (O) • Organizational Unit (OU) • Locality or City (L) • State or Province (S) • Country Name (C)
Issuer: Name of the CA who issued the certificate. The issuer name identifies the entity that signed (and issued) the certificate.
Valid-From: The date the certificate is valid from.
Valid-To: The expiration date.
Signature Algorithm: The algorithm used to create the signature such as sha256WithRSAEncryption.
Subject Alternative Name (SAN) - It may contain otherName, rfc822Name, dNSName, x400Address, directoryName, ediPartyName, uniformResourceIdentifier, iPAddress, registeredID where RFC822 Name - It contains an email address of the user whom this certificate is issued.
Basic Constraints - Basic Constraints are used to indicate whether the certificate belongs to a CA.
Key Usage - Key Usage provides a bitmap[boolean array] specifying the cryptographic operations which may be performed using the public key contained in the certificate; such as Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Certificate Sign, CRL Sign. For example, it could indicate that the key should be used for signatures but not for encipherment.
Extended Key Usage (EKU) - Extended Key Usage is used, typically on a leaf certificate, to indicate the purpose of the public key contained in the certificate such as LS Web Server Authentication, TLS Web Client Authentication, Code Signing, 1.3.6.1.4.1.311.10.3.12, 1.2.840.113583.1.1.5, 0.4.0.2231.3.0, E-mail Protection, Microsoft Smartcardlogin, Any Extended Key Usage. For example, it may indicate that the key may be used on the server end of a TLS or SSL connection or that the key may be used to secure email.
Thumbprint: The hash of the certificate
Thumbprint Algorithm: The algorithm used to create a hash of the certificate.
References
https://docs.oracle.com/javase/8/docs/api/java/security/cert/X509Certificate.html#getKeyUsage--
https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3
https://docs.apigee.com/how-to-guides/validating-certificate-purpose
Formats for X.509 certificates.
There are different formats of X.509 certificates such as PEM, DER, PKCS#7 and PKCS#12.
PEM and PKCS#7 formats use Base64 ASCII encoding while DER and PKCS#12 use binary encoding.
The certificate files have different extensions based on the format and encoding they use.
The following figure illustrates the X.509 Certificate's encoding formats and file extensions.
PEM Format -Privacy Enhanced Mail
Most CAs (Certificate Authority) provide certificates in PEM format in Base64 ASCII encoded files.
The certificate file types can be .pem, .crt, .cer, or .key.
The .pem file can include the server certificate, the intermediate certificate and the private key in a single file. PEM files use ASCII encoding, so you can open them in any text editor such as notepad, MS word etc. Each certificate in the PEM file is contained between the ---- BEGIN CERTIFICATE---- and ----END CERTIFICATE---- statements.
The server certificate and intermediate certificate can also be in a separate .crt or .cer file. .cert or .crt files are certificate signing requests, used by a trusted third party to verify the ownership of a key pair without having direct access to the private key (this is what allows end users, who have no direct knowledge of your website, confident that the certificate is valid). In the self-signed scenario you will use the certificate signing request with your own private key to verify your private key (thus self-signed). The CSR is contained between the -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST----- statements
The private key can be in a .key file. The private key is contained between the ---- BEGIN RSA PRIVATE KEY----- and -----END RSA PRIVATE KEY----- statements.
PKCS#7 Format - Public Key Cryptography Standards
The PKCS#7 format is a Cryptographic Message Syntax Standard.
The PKCS#7 certificate uses Base64 ASCII encoding with file extension .p7b or .p7c.
Only certificates can be stored in this format, not private keys.
The P7B certificates are contained between the "-----BEGIN PKCS7-----" and "-----END PKCS7-----" statements.
PKCS stands for Public Key Cryptography Standards. PKCS#7 is a multi-purpose format for the distribution of encrypted data.
Unlike PEM, PKCS#7 cannot store private keys, only the primary and intermediate certificates.
DER Format - Distinguished Encoding Rules
The DER certificates are in binary form, contained in .der or .cer files.
These certificates are mainly used in Java-based web servers.
All types of certificates and private keys can be encoded in DER format.
PKCS#12 Format - Public Key Cryptography Standards
The PKCS#12 certificates are in binary form, contained in .pfx or .p12 files.
The PKCS#12 can store the server certificate, the intermediate certificate and the private key in a single .pfx file with password protection. These certificates are mainly used on the Windows platform.
Some server systems prompt you to enter a password during the CSR generation, and you can use it to open .pfx files. [PFX - Personal Information Exchange] .
PKCS#12 has lots of options plus extensions (i.e. attribute OIDs) with varying support, so it is not safe to assume that every P12 file will work in anything that uses (some) P12 files.
References
https://www.ssldragon.com/blog/a-complete-guide-to-ssl-certificate-formats/
https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/
https://www.globalsign.com/en-in/ssl-information-center/types-of-ssl-certificate
https://support.citrix.com/article/CTX213224
https://www.digicert.com/wp-content/uploads/2020/05/BPW-Student-Guide-2020-03-v1.pdf
Public key infrastructure
A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.
In cryptography, a PKI is an arrangement that binds public keys with respective identities of entities (like people and organizations). The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA).
Depending on the assurance level of the binding, this may be carried out by an automated process or under human supervision. When done over a network, this requires using a secure certificate enrollment or certificate management protocol such as CMP.
PKI provides "trust services" - in plain terms trusting the actions or outputs of entities, be they people or computers. Trust service objectives respect one or more of the following capabilities: Confidentiality, Integrity and Authenticity (CIA).
Confidentiality: Assurance that no entity can maliciously or unwittingly view a payload in clear text. Data is encrypted to make it secret, such that even if it was read, it appears as gibberish. Perhaps the most common use of PKI for confidentiality purposes is in the context of Transport Layer Security (TLS). TLS is a capability underpinning the security of data in transit, i.e. during transmission. A classic example of TLS for confidentiality is when using an internet browser to log on to a service hosted on an internet based web site by entering a password.
Integrity: Assurance that if an entity changed (tampered) with transmitted data in the slightest way, it would be obvious it happened as its integrity would have been compromised. Often it is not of utmost importance to prevent the integrity being compromised (tamper proof), however, it is of utmost importance that if integrity is compromised there is clear evidence of it having done so (tamper evident).
Authenticity: Assurance that you have certainty of what you are connecting to, or evidencing your legitimacy when connecting to a protected service. The former is termed server-side authentication - typically used when authenticating to a web server using a password. The latter is termed client-side authentication - sometimes used when authenticating using a smart card (hosting a digital certificate and private key).
Certificate Signing Request
A CSR (Certificate Signing Request) is a block of encoded text that is given to a Certificate Authority when applying for a Certificate.
It is usually generated on the server where the certificate will be installed and contains information that will be included in the certificate such as the organization name, common name (domain name), locality, and country.
It also contains the public key that will be included in the certificate. A private key is usually created at the same time that you create the CSR, making a key pair.
Most CSRs are created in the Base-64 encoded PEM format. This format includes the "-----BEGIN CERTIFICATE REQUEST-----" and "-----END CERTIFICATE REQUEST-----" lines at the beginning and end of the CSR.
A certificate authority will use a CSR to create your certificate, but it does not need your private key.
The certificate created with a particular CSR will only work with the private key that was generated with it. So if you lose the private key, the certificate will no longer work.
Cryptographic "salt"
The reason that salts are used is that people tend to choose the same passwords, and not at all randomly. Many used passwords out there are short real words, to make it easy to remember, but this also enables for an attack.
As you may know, passwords are generally not stored in cleartext, but rather hashed. Now, what the attackers can do is to simply generate a list of common passwords and their corresponding hashes. Comparing the hashes that a site has stored with the table will, if common passwords are being used, reveal the passwords to the attacker.
A salt is simply added to make a password hash output unique even for users adopting common passwords. Its purpose is to make pre-computation based attacks unhelpful. If your password is stored with a unique salt then any pre-computed password-hash table targeting unsalted password hashes or targeting an account with a different salt will not aid in cracking your account's password. A long randomly generated salt (using /dev/urandom) is expected to be globally unique. Thus salts can be used to make pre-computation attacks totally ineffective.
The simplest way to combine the salt and the password is to simply concatenate them, i.e. the stored hash value is Hash(salt||password). The common password password1 now magically becomes, e.g., 6$dK,3gCA%Jpassword1 which is unlikely to be found in a password cracker's table.
The salt can be stored completely in the clear in the database, next to the hashed value. Once the attacker has the database and wants to find the passwords, he needs to generate the pre-calculated table for each salt individually, a costly operation. The point of the salt is to make sure that the hash is not found in a precomputed table. It must be stored in order to verify the password (otherwise it's a "pepper"). The salt is not supposed to be "secret", only to make the password unique. This of course means that every stored password must have its own, unique (and random) salt.
Certificate chain
Certificate chain (or Chain of Trust) is made up of a list of certificates that start from a server’s certificate and terminate with the root certificate. The list of certificates, from the root certificate to the end-user certificate, represents the certificate chain.
If your server’s certificate is to be trusted, its signature has to be traceable back to its root CA. In the certificate chain, every certificate is signed by the entity that is identified by the next certified along the chain.
Trusted root CAs are a handful of CAs that are recognized by the clients by default.
Server and intermediate certificates meanwhile could be signed by a CA that is not recognized by the browser. In such an event, the root CA could sign the intermediate CA, which in turn could sign the server certificate.
Now if the client attempts a connection with a server that has a certificate signed by a trusted intermediate CA, the server’s certificates can be traced back to the root certificate through an intermediate certificate and is thus trusted by the client.
The certificate chain simplifies key management and certificate monitoring by “grouping” CAs into a tree-like structure, where verifying the top or root CA automatically verifies the whole chain.
To authenticate the server, your browser will perform a series of checks on the certificate its presented. It will check certificate transparency (CT) logs, online certificate status protocol (OCSP) servers, revocation lists, and the digital signature on the certificate itself. This last part, verifying the digital signature, is where the certificate chain comes in.
What you basically have to do is construct a certificate chain if you didn't get it as a chain. A certificate chain basically consists of the end entity certificate (also, leaf certificate, the most important certificate in the chain) at the zeroth position and followed by the lesser important certificates. The CA Certificate being the least important.
So this is how the usual X.509 certificate chain looks like:
3. CA Certificate (self-signed)
|
|__ 2. Sub CA Certificate (signed by the above CA)
|
|__ 1. Sub-sub CA Certificate (if any) (signed by the above Sub CA)
|
|__ 0. End Entity Certificate (your certificate, signed by the above cert)
When you are constructing a certificate chain yourself from each certificate, you have, you have to see which certificate is signed by whom and then construct the chain in the above manner (the numbers in the tree indicate the index in the java's certificate array).
You can find which certificate is signed by whom by looking at the SubjectDN and IssuerDN. The Subject distinguished name is the end entity, and the Issuer distinguished name is the name of the entity who signed your certificate.
If you need to verify if a certificate is signed by another certificate programmatically, you could do this: - userCert.verify(caCert.getPublicKey());
References
https://www.rapidsslonline.com/ssl/what-is-ssl-certificate-chain/
https://www.appviewx.com/education-center/what-is-a-certificate-chain/
https://support.dnsimple.com/articles/what-is-ssl-certificate-chain/