Archive for July 17th, 2009
Certificates before Certifications! (2/2)
Posted by TacAck in Network Information Store on July 17th, 2009
Alrighty, we know how certificates work and what they do, yadda yadda… Now Lets’s go into the “CERTIFICATE”. Let’s explore the fields present in a certificate , what they mean and how they’re significant.
A Certificate maybe used for many applications like VPN setup ( a big aloha to fellow CCSP’s ), NAC , s-mime, online banking , etc : but they all comply to the ITU-T X.509 standard. Meaning that the format of the certificate is dictated by X.509. PKI uses X.509 version 3 certificates to achieve this. So i went ahead and tried to learn the fields in the X.509 certificate. I found this . Or better yet, let me take a sample certificate and explain the fields to you.
I have with me here the Ceritificate of Thawte Consultancy. (This is a Root CA )
| Field | Value | Meaning |
| Version | V3 | This certificate follows the X.509 v3 hence the Value of “V3”. |
| Serial Number | 00 | This field represents the serial number of the certificate generated by the CA. If it’s the first Certificate generated , then the serial no is 00 and so on . Here it’s 00, because this is the CA certificate ( certificate of the CA) which will obviously be the first certificate generated |
| Signature Algorithm | Md5RSA | This is the algorithm used by the CA to sign the certificate. |
| Issuer | E = personal-basic@thawte.comCN = Thawte Personal Basic CAOU = Certification Services DivisionO = Thawte Consulting
L = Cape Town S = Western Cape C = ZA |
This fields represent the details of the CA who has issued this certificate . Here since it’s the CA’s certificate, it is obvious that it has been issued by itself.This Is a distinguished name. E -> Email address of the issuerCN -> Common Name
OU -> Organisational Unit?? Unsure! O -> Organization L -> Location ( city ) S -> State C – >Country |
| Valid from | Monday, January 01, 1996 5:30:00 AM | Date from which the certificate is valid |
| Valid To | Friday, January 01, 2021 5:29:59 AM | Date until which the certificate is valid |
| Subject | E = personal-basic@thawte.comCN = Thawte Personal Basic CAOU = Certification Services DivisionO = Thawte Consulting
L = Cape Town S = Western Cape C = ZA |
This is the details of the owner of the CA. Here this is same as the issuer because for this certificate the issuer and the subject are the same. |
| Public Key | 30 81 89 02 81 81 00 bc bc 93 53 6d c0 50 4f 82 15 e6 48 94 35 a6 5a be 6f 42 fa 0f 47 ee 77 75 72 dd 8d 49 9b 96 57 a0 78 d4 ca 3f 51 b3 69 0b 91 76 17 22 07 97 6a c4 51 93 4b e0 8d ef 37 95 a1 0c 4d da 34 90 1d 17 89 97 e0 35 38 57 4a c0 f4 08 70 e9 3c 44 7b 50 7e 61 9a 90 e3 23 d3 88 11 46 27 f5 0b 07 0e bb dd d1 7f 20 0a 88 b9 56 0b 2e 1c 80 da f1 e3 9e29 ef 14 bd 0a 44 fb 1b 5b 18 d1 bf 23 93 21 02 03 01 00 01 | This is the Public key of Thawte Personal Basic A. ( Comparing this to our example in part one, this would be the public key of B used for encryption.) |
| Thumbprint Algorithm | Sha1 | Algorithm used for hashing the certificate. This is to ensure that the certificate has not been tampered with during it’s travel. |
| Thumbprint | 40 e7 8c 1d 52 3d 1c d9 95 4f ac 1a 1a b3 bd 3c ba a1 5b fc | This is the HASH value of the certificate. When A receives this certificate, he does a hash of the certificate and compares it with this hash-value. If it’ s identical the certificate is processed further, otherwise rejected. |
There is also another important field in a X.509 v3 certificate which gives the certificate hierarchy. If this certificate was issued by an Intermediate-CA, then the certificate path would contain All the intermediate-CA’s above the issuer along with the topmost ( a.k.a Root CA) . This indicates how the certification process takes place.
I’m in a hurry now, i’m rushing home in a couple of mins, hence the shabby post. I will do some plastic surgery on it once i get back.
Hope you understood atleast half i wanted you to understand. If not, please hit wiki or google .
Certificates before Certifications! (1/2)
Posted by TacAck in Network Information Store on July 17th, 2009
The concept of certificates was something i thought i was “iffy” about. Meaning-> I’d a fair idea what it was but i wouldn’t dare explain it to anyone. You know the feeling right?! So i sat today and looked through some articles about Certificates. And here are my findings.
The magic question : What are certificates?
The not so magical answer : They are ways of identifying people, devices, websites or institutions.
So we know that certificates are used to verify if the other party are who they claim they are. CA’s are the dudes who act as the “verification reference”. Ok here’s an example. If A wants to talk to B but is not sure if the person responding to his questions are actually B, it asks for some proof. B provides a certificate issued by X ( a person that both A and B trust ). Once A gets this certificate and if the certificate is verified to be issued by X, A starts trusting B. So X here is a Certificate Authority ( because he has the authority to issue certificates ). If this clear lets dive in .
The certificate uses public-key encryption technique. To be specific RSA. I’m assuming that you know PKI is. This comes into play in two places.
1) For A to verify that B is producing a certificate assigned to it by X ( who is trusted by A ), X signs the certificate sent to B with the private-key of X. As soon as A gets the certificate , it decrypts it by using X’s public key. If this decryption is successful, A now knows that X created this certificate and assigned it to B. This is because the public-key can only Decrypt data signed by it’s sister Private-key. The private-key is only and Only known by the person it is created for ( X in this case ). So by decrypting the certificate using X’s public key, A confirms that it was encrypted using X’s private key.
2) Now A has authenticated that the certificate is genuine. In order to start communications with B over a insecure network, it has to encrypt the data. The encryption of data must be done by using B’s public key. This is to ensure that upon receiving the encrypted messages from A, B can decrypt it using B’s Private key. This ensures that data confidentiality is achieved. So you might get the question( if you are understand all of this ) , where the F*** does A get the public key of B from? Answer, B’s certificate. Yes, the public key of B is one of the fields in the certificate that B sends over to A .
Ok, to end the introduction, we can now say that the following things happen
- B creates it’s public and private key-pair and sends the public key over the the CA ( X ).
- It begs the CA to issue it a certificate ( ok, beg’s a little too dramatic! )
- CA verifies that B is who he says he is and issues the certificate to B.
- One of the payloads in the certificate is B’s public-key.
- This certificate is signed by X’s private-key for verification of X.
If this is all an overload, re-read. Next article we go into X.509 certificates and their fields….
