JCTDD
asked on
What is the difference between a certificate and a Private/Public key pair?
I started reading:
http://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-ndes-in-active-directory-certificate-services-ad-cs.aspx
where is says:
"At the end of the transactions defined in this protocol, the network device will have a private key and associated certificate that is issued by a CA. Applications on the device may use the key and its associated certificate to interact with other entities on the network."
I've used self-generated Private and Public keys in Windows and Linux before to encrypt and decrypt files with a 3rd party.
What is the difference between a certificate and the Private/Public key pair that I am have used before?
http://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-ndes-in-active-directory-certificate-services-ad-cs.aspx
where is says:
"At the end of the transactions defined in this protocol, the network device will have a private key and associated certificate that is issued by a CA. Applications on the device may use the key and its associated certificate to interact with other entities on the network."
I've used self-generated Private and Public keys in Windows and Linux before to encrypt and decrypt files with a 3rd party.
What is the difference between a certificate and the Private/Public key pair that I am have used before?
A certificate incorporates a public/private key pair, using an asymmetric algorithm such as RSA-2048, in conjunction with other elements of a security infrastructure called PKI.
Public key infrastructure (PKI) is a security infrastructure whose services are delivered and implemented using public key concepts. It provides the foundation necessary for secure e-business through the use of cryptographic keys and digital certificates. This enables secure electronic transactions and the exchange of sensitive information.
Doing business electronically provides the opportunity to deliver new revenue-generating services and lower the cost of traditional business. But as services are delivered electronically, the same security must be provided as in the paper-based world. This security must provide five important capabilities:
Cryptography provides the basis of e-business security. Through encryption and digital signatures, public key cryptography provides those five elements.
When an individual's public key is obtained, the question is how to ensure that the key really is that person's. If that identity cannot be assured, an intruder could substitute his public key for that of the intended receiver. He could then read the message from the sender, change it, and forward it on to the intended receiver using that person's public key, thereby causing the intended receiver to believe that the forged message came from the original sender.
At the heart of PKI is the management of trust. The following are the elements of an efficient and effective PKI. All need to be addressed in order for proper trust to be addressed.
The core services offered by PKI are:
Certification is the process in which someone recognized to be in a position of trust (i.e., the certification authority) uses their own private key to sign a small digital record called, the certificate, that couples an individual's public key to his or her name. Each certificate contains:
The recipient of a digitally signed electronic document relies upon the digital certificate to confirm the relationship between the public key and the identity of the party who is named in the electronic document.
The International Telecommunications Union (ITU) defines a format for public-key certificates in its X.509 (currently version 4) standard.
A Certification Authority (CA) is a trusted entity or third party that signs public key certificates.
The central responsibility of a CA is certifying the authenticity of users, much like the passport-issuing office of a government. A passport is a citizen's secure document, issued by an appropriate authority, which certifies that the citizen is who he/she claims to be. Any country trusting the authority of the first country's government passport office will trust the citizen's passport.
This is a good example of "'third party trust." Third party trust refers to a situation in which two entities or individuals implicitly trust each other, even though they have not previously established a business or personal relationship. In this situation, the two parties implicitly trust each other because they share a relationship with a common third party, and that third party vouches for the trustworthiness of the first two parties.
A certificate, then, is a network user's electronic equivalent of his/her passport. It contains information that can be used to verify the identity of the owner, such as the owner's name. A critical piece of information contained in a user's certificate is that owner's public key.
A CA manages the certificate process:
Most CAs offer various classes of digital certificates, depending on the certifying documents the applicant submits and the fee paid to the CA.
A digital certificate usually contains these elements:
The tasks associated with key management are:
See for more detail http://www.experts-exchang
---
This is incorrect. The certificate must be installed on the web server (whether self-signed or issued by a CA.) In the case of a CA issued certificate, the end users browser checks its local certificate store (Trusted Root Certification Authorities, Intermediate Certification Authorities, etc.) to verify if it can implicitly trust the certificate. If it cannot a warning is produced stating the same. The CA may be referenced for Certificate revocation, however.
---
Here's a detailed report of the certificate presented by CIA.gov
Based on the output, you can clearly see the references to certificate revocation (CRL, OCSP), Signature Algorithm (sha1WithRSAEncryption), RSA Public Key (2048 bit), etc.
Public key infrastructure (PKI) is a security infrastructure whose services are delivered and implemented using public key concepts. It provides the foundation necessary for secure e-business through the use of cryptographic keys and digital certificates. This enables secure electronic transactions and the exchange of sensitive information.
Doing business electronically provides the opportunity to deliver new revenue-generating services and lower the cost of traditional business. But as services are delivered electronically, the same security must be provided as in the paper-based world. This security must provide five important capabilities:
Confidentiality
Access control
Integrity
Authentication
Non-repudiation
Cryptography provides the basis of e-business security. Through encryption and digital signatures, public key cryptography provides those five elements.
When an individual's public key is obtained, the question is how to ensure that the key really is that person's. If that identity cannot be assured, an intruder could substitute his public key for that of the intended receiver. He could then read the message from the sender, change it, and forward it on to the intended receiver using that person's public key, thereby causing the intended receiver to believe that the forged message came from the original sender.
At the heart of PKI is the management of trust. The following are the elements of an efficient and effective PKI. All need to be addressed in order for proper trust to be addressed.
Certification policy
Certification statement
Certificate authority
Registration authority
Certificate repository
Certificate revocation system
Key backup and recovery system
Support for non-repudiation
Automatic key update
Management of key histories
Cross-certification - an extended form of third party trust; a process in which two CAs securely exchange crypto keying information, so that each can effectively certify the trustworthiness of the other's keys
Timestamping
Client side software interacting with all of the above in a consistent, trustworthy manner
The core services offered by PKI are:
Authentication - Assurance to one entity that another entity is who it claims to be
Integrity - Assurance to one entity that the data has not been changed intentionally or unintentionally.
Confidentiality -- Assurance to one entity that only the receiver explicitly intended can read a particular piece of data
Certification is the process in which someone recognized to be in a position of trust (i.e., the certification authority) uses their own private key to sign a small digital record called, the certificate, that couples an individual's public key to his or her name. Each certificate contains:
Name of the certification authority
Public key being certified
Name of the owner of the public key
A unique serial number for this certificate as assigned by the certification authority
Beginning and ending dates for which this certificate is valid
The recipient of a digitally signed electronic document relies upon the digital certificate to confirm the relationship between the public key and the identity of the party who is named in the electronic document.
The International Telecommunications Union (ITU) defines a format for public-key certificates in its X.509 (currently version 4) standard.
A Certification Authority (CA) is a trusted entity or third party that signs public key certificates.
The central responsibility of a CA is certifying the authenticity of users, much like the passport-issuing office of a government. A passport is a citizen's secure document, issued by an appropriate authority, which certifies that the citizen is who he/she claims to be. Any country trusting the authority of the first country's government passport office will trust the citizen's passport.
This is a good example of "'third party trust." Third party trust refers to a situation in which two entities or individuals implicitly trust each other, even though they have not previously established a business or personal relationship. In this situation, the two parties implicitly trust each other because they share a relationship with a common third party, and that third party vouches for the trustworthiness of the first two parties.
A certificate, then, is a network user's electronic equivalent of his/her passport. It contains information that can be used to verify the identity of the owner, such as the owner's name. A critical piece of information contained in a user's certificate is that owner's public key.
A CA manages the certificate process:
Digital certificate application
Certification (authentication of the applicant)
Issuance of the certificate
Revocation
Most CAs offer various classes of digital certificates, depending on the certifying documents the applicant submits and the fee paid to the CA.
Low assurance certificate - does not provide proof of identity
High assurance certificates - requires stringent credentials at registration
A digital certificate usually contains these elements:
Version: Identifies the version of the certificate
Serial Number: Unique number for the certificate
Algorithm ID: Algorithm used to sign the certificate
Issuer: Name of the certificate authority
Validity: Validity dates
Subject: Name of owner
Subject Public Key info: Public Key of Owner
Issuer Unique ID: ID of issuing CA
Subject unique ID: ID of subject
[Blank]: Optional extensions
Digital Signature: All previous fields signed by CA
The tasks associated with key management are:
Key generation
Key distribution
Key change
Key disposition
Key recovery
Control of cryptography keys
See for more detail http://www.experts-exchang
---
The owner of the certificate does not need to share that key.
Whenever any client/computer accesses your website that has certificate it goes to Certificate Authority to search for Public key that's related with that certificate.
This is incorrect. The certificate must be installed on the web server (whether self-signed or issued by a CA.) In the case of a CA issued certificate, the end users browser checks its local certificate store (Trusted Root Certification Authorities, Intermediate Certification Authorities, etc.) to verify if it can implicitly trust the certificate. If it cannot a warning is produced stating the same. The CA may be referenced for Certificate revocation, however.
---
Here's a detailed report of the certificate presented by CIA.gov
Based on the output, you can clearly see the references to certificate revocation (CRL, OCSP), Signature Algorithm (sha1WithRSAEncryption), RSA Public Key (2048 bit), etc.
Testing SSL server cia.gov on port 443
Supported Server Cipher(s):
Accepted SSLv3 256 bits AES256-SHA
Accepted SSLv3 128 bits AES128-SHA
Accepted SSLv3 168 bits DES-CBC3-SHA
Accepted SSLv3 128 bits RC4-SHA
Accepted SSLv3 128 bits RC4-MD5
Accepted TLSv1 256 bits AES256-SHA
Accepted TLSv1 128 bits AES128-SHA
Accepted TLSv1 168 bits DES-CBC3-SHA
Accepted TLSv1 128 bits RC4-SHA
Accepted TLSv1 128 bits RC4-MD5
Prefered Server Cipher(s):
SSLv3 256 bits AES256-SHA
TLSv1 256 bits AES256-SHA
SSL Certificate:
Version: 2
Serial Number: -4294967295
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
Not valid before: Apr 8 00:00:00 2013 GMT
Not valid after: Apr 8 23:59:59 2015 GMT
Subject: /1.3.6.1.4.1.311.60.2.1.3=US/busines sCategory= Government Entity/serialNumber=Govern ment Entity/C=US/ST=Virginia/L= McLean/O=C entral Intelligence Agency/OU=Operations 1/OU=Terms of use at www.verisign.com/rpa (c)05/CN=www.cia.gov
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:a5:b6:f2:36:e5:3c:c4:38:e8:c4:d5: 88:01:47:
65:78:01:aa:7b:f7:8b:96:ef:2c:af:d9: 76:23:38:
7d:34:cd:93:64:9e:a7:3a:d8:b4:70:a0: af:e7:fd:
88:d5:0b:be:c7:c0:63:a4:e2:6f:06:d9: e4:ee:9c:
11:19:2f:4d:18:01:5b:87:3d:fb:52:ee: be:2b:41:
f2:2a:d4:e0:66:7f:57:0c:bd:56:38:b8: 5b:f0:10:
43:0d:a1:82:43:0a:c7:3f:2a:8a:2e:d4: 63:43:4b:
30:72:09:ba:4e:f2:de:d2:8f:37:d3:3c: be:90:34:
2c:55:9d:cb:36:8b:63:4c:68:b2:9b:fb: 02:81:cb:
28:6b:be:3b:c8:c3:0d:f4:b1:3a:73:fb: 19:79:ac:
1d:30:cc:6f:52:7a:d7:bc:41:a4:4a:b7: 6b:b0:5e:
9e:5a:26:91:60:39:84:f2:e8:0c:dc:87: 66:f7:2e:
5e:2b:ec:2c:87:3b:2d:23:33:8f:de:4e: 1e:b6:10:
3f:f7:8f:30:cc:31:b2:f7:7b:56:36:27: d4:44:eb:
0b:76:df:f4:ba:25:a2:6d:b7:97:e1:1a: 1b:b8:31:
89:a4:61:f2:ad:7e:e0:49:c3:34:34:66: 70:95:24:
cf:7c:f9:4c:5e:40:d0:47:72:66:57:80: 7b:05:b0:
c5:87
Exponent: 65537 (0x10001)
X509v3 Extensions:
X509v3 Subject Alternative Name:
DNS:www.cia.gov
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.23.6
CPS: https://www.verisign.com/cps
X509v3 CRL Distribution Points:
URI:http://EVIntl-crl.verisign.com/EVIntl2006.crl
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto
X509v3 Authority Key Identifier:
keyid:4E:43:C8:1D:76:EF:37:53:7A:4F: F2:58:6F:9 4:F3:38:E2 :D5:BD:DF
Authority Information Access:
OCSP - URI:http://ocsp.verisign.com
CA Issuers - URI:http://EVIntl-aia.verisign.com/EVIntl2006.cer
A simpler answer:
Certificate is an signed electronic document that contains:
- A public key
- Information on the owner
The public key is associated to a private key, just as the keys you have told us you already used. But the private key is NOT inside the certificate. The certificate is a public file just as your public key file.
This electronic document is signed by a Certification Authority, that is a entity that has his own private and public key pair, and its own certificate, that is signed by another CA, until you have a CA that is self-signed and is therefore called a Root CA. This CA you need to trust directly, and your computer always trust a lot of them by default.
If you have a chain of valid signatures from your certificate to a trusted root CA, you trust the certificate. By trust, I mean you know that the data in the certificate is legitimate, therefore the public key on it is associated to the information about the owner of that key and the private key owner is the one that is in the certificate data.
Therefore, certificate is just the way you can be sure (as long as you trust CAs) that a given key really is from someone. And that is very important, for signing (you need to be sure who is the one that owns a key) and also for encryption (if you want to send me something encrypted, how would you make sure that the key you find on internet is really mine? you need something to check this, and certificate is also for that).
PS: Certificates do contain more details, like validity, revocation, etc. But I´ll let this out for this moment.
Certificate is an signed electronic document that contains:
- A public key
- Information on the owner
The public key is associated to a private key, just as the keys you have told us you already used. But the private key is NOT inside the certificate. The certificate is a public file just as your public key file.
This electronic document is signed by a Certification Authority, that is a entity that has his own private and public key pair, and its own certificate, that is signed by another CA, until you have a CA that is self-signed and is therefore called a Root CA. This CA you need to trust directly, and your computer always trust a lot of them by default.
If you have a chain of valid signatures from your certificate to a trusted root CA, you trust the certificate. By trust, I mean you know that the data in the certificate is legitimate, therefore the public key on it is associated to the information about the owner of that key and the private key owner is the one that is in the certificate data.
Therefore, certificate is just the way you can be sure (as long as you trust CAs) that a given key really is from someone. And that is very important, for signing (you need to be sure who is the one that owns a key) and also for encryption (if you want to send me something encrypted, how would you make sure that the key you find on internet is really mine? you need something to check this, and certificate is also for that).
PS: Certificates do contain more details, like validity, revocation, etc. But I´ll let this out for this moment.
ASKER
If I set up (I'm still learning about this) 802.1x authentication (with MS NPS and AD CS and automatic certificate enrollment), my workstation would receive a:
machine certificate?
user certificate?
And the certificate located on my hard disk would only contain the Public Key? The Issuing CA stores the Private Key for me?
machine certificate?
user certificate?
And the certificate located on my hard disk would only contain the Public Key? The Issuing CA stores the Private Key for me?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The owner of the certificate does not need to share that key.
Whenever any client/computer accesses your website that has certificate it goes to Certificate Authority to search for Public key that's related with that certificate.
So Certificate has information such as who's owner, who has issued that certificate, Encryption methodology used for that certificate and such relevant details.
One can have Self Signed certificate where he/she issues the certificate on it's own and does not register that certificate with verified CA (Hence you do not need to pay for the certificate) but in such case as certificate isn't verified it will show image such as
Certificate.png