Certificates

From Network Security Wiki


Public-key cryptography

  • Asymmetric cryptography is a cryptographic system that uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner.
  • The generation of such keys depends on cryptographic algorithms based on mathematical problems to produce one-way functions.
  • Effective security only requires keeping the private key private; the public key can be openly distributed without compromising security.
  • In such a system, any person can encrypt a message using the receiver's public key, but that encrypted message can only be decrypted with the receiver's private key.
Digital Signature
  • A sender can combine a message with a private key to create a short digital signature on the message.
  • Anyone with the sender's corresponding public key can combine the same message and the supposed digital signature associated with it to verify whether the signature was valid, i.e. made by the owner of the corresponding private key.
Prime Numbers & Encryption
  • Product of 2 large random Prime Numbers is the backbone of Encryption.
11 x 17 = 187
  • Cracking the encryption means figuring out the 2 factors.
  • Using Brute Force it takes decades with today's computers.
  • If 2 numbers are known (a private key), it takes a split second.
  • The numbers in largest known prime number: 17,425,170.
  • The Public key is made up in part by calculating the number of integers that share no common factors that are less than the product of 2 Prime Numbers.

X.509 Certificate

  • In cryptography, X.509 is a standard defining the format of public key certificates.
  • X.509 certificates are used in many protocols like TLS/SSL, which is the basis for HTTPS.
  • They are also used in offline applications like Electronic Signatures.
  • It contains a public key and an identity - hostname, organization or individual.
  • It is either signed by a Certificate Authority or Self-Signed.
  • When a certificate is signed by a trusted certificate authority or validated by other means, someone holding that certificate can rely on the public key it contains.
  • X.509 also defines certificate revocation lists, which are a means to distribute information about certificates that have been deemed invalid by a signing authority, as well as a certification path validation algorithm, which allows for certificates to be signed by intermediate CA certificates, which are, in turn, signed by other certificates, eventually reaching a trust anchor.
Working of Certificates
  • In the X.509 system, an organization that wants a signed certificate requests one via a Certificate Signing Request (CSR).
  • To do this, it first generates a key pair, keeping the private key secret and using it to sign the CSR.
  • This contains information identifying the applicant and the applicant's public key that is used to verify the signature of the CSR - and the Distinguished Name (DN) that the certificate is for.
  • The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority.
  • The Certification Authority issues a certificate binding a public key to a particular distinguished name.
  • An organization's trusted root certificates can be distributed to all employees so that they can use the company PKI system.
  • Browsers such as Internet Explorer, Firefox, Opera, Safari and Chrome come with a predetermined set of root certificates pre-installed.
  • SSL certificates from major certificate authorities will work instantly.
Structure of an X.509 v3 Digital certificate
  • Certificate
    • Version Number
    • Serial Number
    • Signature Algorithm ID
    • Issuer Name
    • Validity period
      • Not Before
      • Not After
    • Subject name
    • Subject Public Key Info
      • Public Key Algorithm
      • Subject Public Key
    • Issuer Unique Identifier (optional)
    • Subject Unique Identifier (optional)
    • Extensions (optional)
  • Certificate Signature Algorithm
  • Certificate Signature


  • The serial number must be unique for each certificate issued by a specific CA.

OpenSSL

Source: sslshopper.com

Generate Certificates

  • Generate a new private key and Certificate Signing Request
openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key
  • Generate a self-signed certificate
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
  • Generate a certificate signing request (CSR) for an existing private key
openssl req -out CSR.csr -key privateKey.key -new
  • Generate a certificate signing request based on an existing certificate
 openssl x509 -x509toreq -in certificate.crt -out CSR.csr -signkey privateKey.key
  • Remove a passphrase from a private key
openssl rsa -in privateKey.pem -out newPrivateKey.pem

Verifying Certificates

  • Check a Certificate Signing Request (CSR)
openssl req -text -noout -verify -in CSR.csr
  • Check a private key
openssl rsa -in privateKey.key -check
  • Check a certificate
openssl x509 -in certificate.crt -text -noout
  • Check a PKCS#12 file (.pfx or .p12)
openssl pkcs12 -info -in keyStore.p12

Debugging

  • Check an MD5 hash of the public key to ensure that it matches with what is in a CSR or private key
openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in privateKey.key | openssl md5
openssl req -noout -modulus -in CSR.csr | openssl md5
  • Check an SSL connection. All the certificates (including Intermediates) should be displayed
openssl s_client -connect www.paypal.com:443

Converting Format

  • Convert a DER file (.crt .cer .der) to PEM
openssl x509 -inform der -in certificate.cer -out certificate.pem
  • Convert a PEM file to DER
openssl x509 -outform der -in certificate.pem -out certificate.der
  • Convert a PKCS#12 file (.pfx .p12) containing a private key and certificates to PEM
openssl pkcs12 -in keyStore.pfx -out keyStore.pem -nodes

You can add -nocerts to only output the private key or add -nokeys to only output the certificates.

  • Convert a PEM certificate file and a private key to PKCS#12 (.pfx .p12)
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt


Troubleshooting

Misc

​

A session symmetric key between two parties is used only once.

The symmetric (shared) key in the Diffie-Hellman method is K = g xy mod p.

In public-key cryptography, everyone has access to everyone’s public key;
public keys are available to the public.


Our example uses small numbers, but
note that in a real situation, the numbers are very large. Assume that g = 7 and p = 23. The steps
are as follows:
1. Alice chooses x = 3 and calculates R 1 = 7 3 mod 23 = 21.
2. Alice sends the number 21 to Bob.
3. Bob chooses y = 6 and calculates R 2 = 7 6 mod 23 = 4.
4. Bob sends the number 4 to Alice.
5. Alice calculates the symmetric key K = 4 3 mod 23 = 18. Bob calculates the symmetric key
K = 21 6 mod 23 = 18.
The value of K is the same for both Alice and Bob; g xy mod p = 7 18 mod 35 = 18.



Public Announcement:
The naive approach is to announce public keys publicly. Bob can put his public key on
his website or announce it in a local or national newspaper. When Alice needs to send a
confidential message to Bob, she can obtain Bob’s public key from his site or from the
newspaper, or even send a message to ask for it. This approach, however, is not secure; it is subject to forgery. For example, Eve could make such a public announcement.
Before Bob can react, damage could be done. Eve can fool Alice into sending her a
message that is intended for Bob. Eve could also sign a document with a corresponding
forged private key and make everyone believe it was signed by Bob. The approach is
also vulnerable if Alice directly requests Bob’s public key. Eve can intercept Bob’s
response and substitute her own forged public key for Bob’s public key.

----

CSR has a Public Key.

CA signs it.

Certificate is a proof of public key.

Encrypt using public key & receiver decrypts using private key.

There are two types of certificate authorities (CAs), root CAs and intermediate CAs. 

    Certificate 1 - Issued To: example.com; Issued By: Intermediate CA 1
    Certificate 2 - Issued To: Intermediate CA 1; Issued By: Intermediate CA 2
    Certificate 3 - Issued To: Intermediate CA 2; Issued By: Intermediate CA 3
    Certificate 4 - Issued To: Intermediate CA 3; Issued By: Root CA 

Root CA certificates, on the other hand, are "Issued To" and "Issued By" themselves,

For enhanced security purposes, most end user certificates today are issued by intermediate certificate authorities.

Installing an intermediate CA signed certificate on a web server or load balancer usually requires installing a bundle of certificates.

The CA will also provide a so called intermediate CA file or chain certificate. 
It proves that your chosen CA is trusted by one of the root CAs. 
You will need the intermediate CA certificate as 'chain' certificate in your clientssl profile.

Nonce is Number Once
----
In an asymmetric key encryption scheme, anyone can encrypt messages using the public key, but only the holder of the paired private key can decrypt. 
Security depends on the secrecy of the private key.

In the Diffie–Hellman key exchange scheme, each party generates a public/private key pair and distributes the public key. 
After obtaining an authentic copy of each other's public keys, Alice and Bob can compute a shared secret offline. 
The shared secret can be used, for instance, as the key for a symmetric cipher.

----
*Public-key encryption, in which a message is encrypted with a recipient's public key. The message cannot be decrypted by anyone who does not possess the matching private key, who is thus presumed to be the owner of that key and the person associated with the public key. This is used in an attempt to ensure confidentiality.

*Digital signatures, in which a message is signed with the sender's private key and can be verified by anyone who has access to the sender's public key. This verification proves that the sender had access to the private key, and therefore is likely to be the person associated with the public key. This also ensures that the message has not been tampered with, as any manipulation of the message will result in changes to the encoded message digest, which otherwise remains unchanged between the sender and receiver.



References





{{#widget:DISQUS |id=networkm |uniqid=Certificates |url=https://aman.awiki.org/wiki/Certificates }}

Retrieved from "https://aman.awiki.org/wiki/Certificates?oldid=4664"