Definitions of SSL certificate on the Web:
How to verify that a private key goes with a certificate
(Shamelessly stolen from (and expanding upon) The Apache SSL FAQ)
The private key contains a series of numbers. Two of those numbers form the "public key", the others are part of your "private key". The "public key" bits are also embedded in your Certificate (we get them from your CSR). To check that the public key in your cert matches the public portion of your private key, you need to view the cert and the key and compare the numbers. To view the Certificate and the key run the commands:
$openssl x509 -noout -text -in server.crt $openssl rsa -noout -text -in server.key
The `modulus' and the `public exponent' portions in the key and the Certificate must match. But since the public exponent is usually 65537 and it's bothering comparing long modulus you can use the following approach:
$openssl x509 -noout -modulus -in server.crt | openssl md5 $openssl rsa -noout -modulus -in server.key | openssl md5
And then compare these really shorter numbers. With overwhelming probability they will differ if the keys are different. As a one-liner
:
$openssl x509 -noout -modulus -in server.pem | openssl md5 ;\ openssl rsa -noout -modulus -in server.key | openssl md5
And with auto-magic comparison (If more than one hash is displayed, they don't match):
$(openssl x509 -noout -modulus -in server.pem | openssl md5 ;\ openssl rsa -noout -modulus -in server.key | openssl md5) | uniq
BTW, if I want to check to which key or certificate a particular CSR belongs you can compute
$openssl req -noout -modulus -in server.csr | openssl md5
In public key infrastructure systems, a certificate signing request (also CSR or certification request) is a message sent from an applicant to a certificate authority in order to apply for a digital identity certificate. Before creating a CSR, the applicant first generates a key pair, keeping the private key secret. The CSR contains information identifying the applicant (such as a distinguished name in the case of an X.509 certificate), and the public key chosen by the applicant. The corresponding private key is not included in the CSR, but is used to digitally sign the entire request. The CSR may be accompanied by other credentials or proofs of identity required by the certificate authority, and the certificate authority may contact the applicant for further information.
If the request is successful, the certificate authority will send back an identity certificate that has been digitally signed with the private key of the certificate authority.
The PKCS#10 standard defines a binary format for encoding CSRs for use with X.509. It is expressed in ASN.1. Here is an example of how you can examine its ASN.1 structure using OpenSSL :
openssl asn1parse -in your_request
A CSR may be represented as a Base64 encoded PKCS#10; an example of which is given below:
-----BEGIN CERTIFICATE REQUEST----- MIIBnTCCAQYCAQAwXTELMAkGA1UEBhMCU0cxETAPBgNVBAoTCE0yQ3J5cHRvMRIw EAYDVQQDEwlsb2NhbGhvc3QxJzAlBgkqhkiG9w0BCQEWGGFkbWluQHNlcnZlci5l eGFtcGxlLmRvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr1nYY1Qrll1r uB/FqlCRrr5nvupdIN+3wF7q915tvEQoc74bnu6b8IbbGRMhzdzmvQ4SzFfVEAuM MuTHeybPq5th7YDrTNizKKxOBnqE2KYuX9X22A1Kh49soJJFg6kPb9MUgiZBiMlv tb7K3CHfgw5WagWnLl8Lb+ccvKZZl+8CAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GB AHpoRp5YS55CZpy+wdigQEwjL/wSluvo+WjtpvP0YoBMJu4VMKeZi405R7o8oEwi PdlrrliKNknFmHKIaCKTLRcU59ScA6ADEIWUzqmUzP5Cs6jrSRo3NKfg1bd09D1K 9rsQkRc9Urv9mRBIsredGnYECNeRaK5R1yzpOowninXC -----END CERTIFICATE REQUEST-----
There are two types of certificate authorities (CAs), root CAs and intermediate CAs. In order for a certificate to be trusted, and often for a secure connection to be established at all, that certificate must have been issued by a CA that is included in the trusted store of the device that is connecting.
If the certificate was not issued by a trusted CA, the connecting device (e.g., a web browser) will then check to see if the issuing CA of the certificate was issued by a trusted CA, and so on until either a trusted CA is found (at which point a trusted, secure connection will be established) or no trusted CA can be found (at which point the device will usually display an error).
To facilitate this process of verifying a "chain" of trust, every certificate includes the fields "Issued To" and "Issued By". An intermediate CA will show different information in these two fields, showing a connecting device where to continue checking, if necessary, in order to establish trust.
Root CA's, on the other hand, are "Issued To" and "Issued By" themselves, so no further checking is possible or necessary in order to establish trust (or lack thereof).
For example, if I have a certificate issued to "mysite.com" and issued by "Intermediate CA1", and my web browser trusts "Root CA", trust may be established in the following manner.
Certificate 1 - Issued To: mysite.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 3 - Issued To: Intermediate CA 3; Issued By: Root CA
My browser trusts "Root CA", and a secure connection can now be established. Since this process is often called "certificate chaining," intermediate CA certs are sometimes called "chained certificates". 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.
In a related but distinct usage of the phrase, "Intermediate CA" may refer to a certificate issuing organization that does not, or is unable to issue certificates that chain to a Root CA that is owned by that organization (perhaps due to practical limitations, such as certificate ubiquity). Such an organization may be classified by some as a white label reseller.
Here the ambiguity comes from the use of the term "certificate authority", which can refer either to a certificate issuing organization or the certificates used by those organizations to issue end-user certificates.
7. SSL Costs?The information provided on this page comes without any warranty whatsoever. Use it at your own risk. Just because a program, book, document or service is listed here or has a good review does not mean that I endorse or approve of the program or of any of its contents. All the other standard disclaimers also apply.
This organisation allows you to create certificates, including wildcard certificates (which means it is valid for any subdomain of your domain), to protect your connections to your websites or your email via POP3, SMTP and IMAP. You can create certs with any encryption strength you wish.
This company provides free digital certificates signed by StartCom, so that you can create an SSL secured site with encryption. You are allowed as many certificates as you wish. You will need to provide your personal details. Verification of your identity is done every year while validation of your domain name is done every 30 days. WARNING: although the certificate is free, the verifications/validations are not.
To request and install a Microsoft IIS web server certificate:
OpenSSL is based on the excellent SSLeay library developed by Eric A. Young and Tim J. Hudson. The OpenSSL toolkit is licensed under an Apache-style licence, which basically means that you are free to get and use it for commercial and non-commercial purposes subject to some simple license conditions.