Creating digital certificates with our root certificate - Revision history

Saruman!: /* CA.sh - certificate creation made easy */ typo's

2012-08-16T09:33:33Z

CA.sh - certificate creation made easy: typo's

← Older revision		Revision as of 09:33, 16 August 2012
Line 69:		Line 69:

	To remove the passphrase from the private key, use a command like this:		To remove the passphrase from the private key, use a command like this:
	openssl rsa -in shop.saruman.biz.seckey.~~key~~ -out shop.saruman.biz.~~key~~.~~key~~		openssl rsa -in shop.saruman.biz.seckey.pem -out shop.saruman.biz.nokey.pem
	This will make ''openssl'' ask for your passphrase, and then create the unsecured ''shop.saruman.biz.~~key~~.pem'' key file. Best practice: ALWAYS use a passphrase-protected key, unless the application cannot support it (e.g. Postfix).		This will make ''openssl'' ask for your passphrase, and then create the unsecured ''shop.saruman.biz.nokey.pem'' key file. Best practice: ALWAYS use a passphrase-protected key, unless the application cannot support it (e.g. Postfix).

	Save the secure private key and its PEM passphrase in a safe place (e.g. Keepass database). And if you removed the passphrase from the private key, then store it in an even safer place!		Save the secure private key and its PEM passphrase in a safe place (e.g. Keepass database). And if you removed the passphrase from the private key, then store it in an even safer place!

Insomnia: /* Preparing for certificate creation */

2009-08-28T07:48:18Z

Preparing for certificate creation

← Older revision		Revision as of 07:48, 28 August 2009
Line 7:		Line 7:
	However, we're going to need to input a lot of parameters on the ''openssl'' command line. We can make things a bit easier for us by specifying these in the ''openssl.cnf'' file, just as we have added some values when creating the CA itself. To be precise, we're going to add '''X.509 V3 extensions'''		However, we're going to need to input a lot of parameters on the ''openssl'' command line. We can make things a bit easier for us by specifying these in the ''openssl.cnf'' file, just as we have added some values when creating the CA itself. To be precise, we're going to add '''X.509 V3 extensions'''

	By default OpenSSL generates V1 certificates, but if we're not extremely worried about offending certain ancient web browsers, we can add V3 extensions, and even make ''openssl'' do that by default. To do this, we find in ''openssl.cnf'' the following line in the section ''[ req ]'', which is likely present but commented out:		By default OpenSSL generates V1 certificates, but if we're not extremely worried about offending certain ancient web browsers, we can add V3 extensions, and even make ''openssl'' do that by default. To do this, we find in ''/etc/ssl/openssl.cnf'' the following line in the section ''[ req ]'', which is likely present but commented out:
	req_extensions = v3_req # The extensions to add to a certificate request		req_extensions = v3_req # The extensions to add to a certificate request
	Simply remove the # sign in front of it, so that it appears as given above. This by default enables V3 extensions.		Simply remove the # sign in front of it, so that it appears as given above. This by default enables V3 extensions.

217.128.70.172: /* CA.sh - certificate creation made easy */

2009-04-29T15:17:28Z

CA.sh - certificate creation made easy

← Older revision		Revision as of 15:17, 29 April 2009
Line 66:		Line 66:
	* delete ''newreq.pem''		* delete ''newreq.pem''
	* rename the generated private key ''newkey.pem'' to ''shop.saruman.biz.seckey.pem''		* rename the generated private key ''newkey.pem'' to ''shop.saruman.biz.seckey.pem''
	* rename ~~hte~~ generated public certificate ''newcert.pem'' to ''shop.saruman.biz.pem''		* rename the generated public certificate ''newcert.pem'' to ''shop.saruman.biz.pem''

	To remove the passphrase from the private key, use a command like this:		To remove the passphrase from the private key, use a command like this:
	openssl rsa -in shop.saruman.biz.seckey.~~pem~~ -out shop.saruman.biz.key.~~pem~~		openssl rsa -in shop.saruman.biz.seckey.key -out shop.saruman.biz.key.key
	This will make ''openssl'' ask for your passphrase, and then create the unsecured ''shop.saruman.biz.key.pem'' key file. Best practice: ALWAYS use a passphrase-protected key, unless the application cannot support it (e.g. Postfix).		This will make ''openssl'' ask for your passphrase, and then create the unsecured ''shop.saruman.biz.key.pem'' key file. Best practice: ALWAYS use a passphrase-protected key, unless the application cannot support it (e.g. Postfix).

Saruman!: /* CA.sh - certificate creation made easy */ added passphrase removal

2009-01-13T20:18:03Z

CA.sh - certificate creation made easy: added passphrase removal

← Older revision		Revision as of 20:18, 13 January 2009
Line 28:		Line 28:
	/usr/lib/ssl/misc/CA.sh -newreq		/usr/lib/ssl/misc/CA.sh -newreq
	This will create the signing request. The questions it'll ask, are		This will create the signing request. The questions it'll ask, are
	* a PEM passphrase, with which to protect the private key of the key pair		* a PEM passphrase, with which to protect the private key of the key pair. Note: you cannot generate a signing request without passphrase, so the private key you'll generate will ''always'' have a passphrase. If this is not what you want, do not despair: you can easily remove the passphrase from the private key after it's been generated (see further down). So just use a passphrase, even if you don't need one.
	* Country/State/Locality/Organization/Organizational Unit; just as with the CA root certificate creation, these have your preprogrammed defaults that you may or may not change.		* Country/State/Locality/Organization/Organizational Unit; just as with the CA root certificate creation, these have your preprogrammed defaults that you may or may not change.
	* Common Name; here we MUST give the DNS name of the host that is going to use the certificate, e.g. ''shop.saruman.biz'', or ''*.saruman.biz''.		* Common Name; here we MUST give the DNS name of the host that is going to use the certificate, e.g. ''shop.saruman.biz'', or ''*.saruman.biz''.
Line 63:		Line 63:
	After doing your CA duty and diligently checking all the data, just press ''y''. The script certifies the request, and asks if it is to commit the request. This means it'll update it's own database, by saving a copy of the signed certificate in ''/etc/ssl/ca/newcerts'' named after its serial number (''01.pem'' for this example). Furthermore the script will record the serial and ID's of the generated certificate so that the next certificate will have a new serial number. And now: hey presto! We have a ''newcert.pem'' in our working directory!		After doing your CA duty and diligently checking all the data, just press ''y''. The script certifies the request, and asks if it is to commit the request. This means it'll update it's own database, by saving a copy of the signed certificate in ''/etc/ssl/ca/newcerts'' named after its serial number (''01.pem'' for this example). Furthermore the script will record the serial and ID's of the generated certificate so that the next certificate will have a new serial number. And now: hey presto! We have a ''newcert.pem'' in our working directory!

	For good measure: delete ''newreq.pem'', rename ''newkey.pem'' to ''shop.saruman.biz.~~key~~.pem''~~, and~~ rename ''newcert.pem'' to ''shop.saruman.biz.pem''. Save the private key and its PEM passphrase in a safe place (e.g. Keepass database), ~~and~~ deploy your certificate! (more on that in another section).		For good measure:
			* delete ''newreq.pem''
			* rename the generated private key ''newkey.pem'' to ''shop.saruman.biz.seckey.pem''
			* rename hte generated public certificate ''newcert.pem'' to ''shop.saruman.biz.pem''

			To remove the passphrase from the private key, use a command like this:
			openssl rsa -in shop.saruman.biz.seckey.pem -out shop.saruman.biz.key.pem
			This will make ''openssl'' ask for your passphrase, and then create the unsecured ''shop.saruman.biz.key.pem'' key file. Best practice: ALWAYS use a passphrase-protected key, unless the application cannot support it (e.g. Postfix).

			Save the secure private key and its PEM passphrase in a safe place (e.g. Keepass database). And if you removed the passphrase from the private key, then store it in an even safer place!

			Now you can deploy your certificate. (more on that in another section).

	=== openssl - the hard way to certificate creation===		=== openssl - the hard way to certificate creation===

Saruman!: Finished CA cert creation part

2008-10-28T08:09:57Z

Finished CA cert creation part

@@ Line 24: / Line 24: @@
 Now we can create an SSL certificate for a web server. For the Common Name of the certificate, we need the '''exact''' name of the web server that'll offer the SSL connections. However, some servers run different websites as Virtual Hosts, so they could be running, for example, www.saruman.biz, as well as shop.saruman.biz. That might present a problem, because if the certificate is issued for www.saruman.biz, then each visitor of shop.saruman.biz will get a warning along the lines of "Warning: The website you're trying to visit is shop.saruman.biz, but the certificate offered is for www.saruman.biz". To prevent that, we could use the wildcard character in the name of the certificate, so as to generate a certificate for *.saruman.biz.
-So with that out of the way, we now perform the first step in our certificate generation: we create a signing request with all the information that we want in our SSL certificate. We run the magic incantation
+=== CA.sh - certificate creation made easy===
-  openssl req -new -nodes -keyout saruman.biz.mykey.pem -out saruman.biz.req.pem
+Since we have the ''openssl.cnf'' set up just right, and the ''CA.sh'' script primed, generating an SSL certificate is not very hard. From any old directory, run as root
-This generates a new private key (named ''saruman.biz.mykey.pem''), and a new, non-encrypted (because of ''-nodes''), key signing request named ''saruman.biz.req.pem''. We can leave out terms like ''-newkey rsa:2048'' and ''-days 370'' since we've put that in the configuration file. And naturally you're free to choose your own names for the keys.
+ /usr/lib/ssl/misc/CA.sh -newreq

Saruman!: Page started

2008-10-27T23:20:21Z

Page started

New page

==Preparing for certificate creation==
When we're going to create certificates, we're going to use the ''openssl'' command twice:
* once to create a "certificate signing request", in which we define all information to be included in the certificate, and actually generate the public and private key parts of the key pair, and
* once to instruct the OpenSSL package to sign the certificate with our CA root certificate.
The first step thus '''creates''' the actual keypair, and the second step '''signs''' the public key.

However, we're going to need to input a lot of parameters on the ''openssl'' command line. We can make things a bit easier for us by specifying these in the ''openssl.cnf'' file, just as we have added some values when creating the CA itself. To be precise, we're going to add '''X.509 V3 extensions'''

By default OpenSSL generates V1 certificates, but if we're not extremely worried about offending certain ancient web browsers, we can add V3 extensions, and even make ''openssl'' do that by default. To do this, we find in ''openssl.cnf'' the following line in the section ''[ req ]'', which is likely present but commented out:
req_extensions = v3_req # The extensions to add to a certificate request
Simply remove the # sign in front of it, so that it appears as given above. This by default enables V3 extensions.

Furthermore, check the section ''[ v3_req ]''. It should look like this:
[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectKeyIdentifier = hash
What is added is the last line, with ''subjectKeyIdentifier''; this line specifies how to identify the public key being certified, so that distinct keys used by the same subject can be differentiated (e.g. as key updating occurs, for example). Four values are possible, but the IETF Public Key Infrastructure (PKIX) working group recommends the setting ''subjectKeyIdentifier=hash''

==Creating an SSL certificate==
Now we can create an SSL certificate for a web server. For the Common Name of the certificate, we need the '''exact''' name of the web server that'll offer the SSL connections. However, some servers run different websites as Virtual Hosts, so they could be running, for example, www.saruman.biz, as well as shop.saruman.biz. That might present a problem, because if the certificate is issued for www.saruman.biz, then each visitor of shop.saruman.biz will get a warning along the lines of "Warning: The website you're trying to visit is shop.saruman.biz, but the certificate offered is for www.saruman.biz". To prevent that, we could use the wildcard character in the name of the certificate, so as to generate a certificate for *.saruman.biz.

So with that out of the way, we now perform the first step in our certificate generation: we create a signing request with all the information that we want in our SSL certificate. We run the magic incantation
openssl req -new -nodes -keyout saruman.biz.mykey.pem -out saruman.biz.req.pem
This generates a new private key (named ''saruman.biz.mykey.pem''), and a new, non-encrypted (because of ''-nodes''), key signing request named ''saruman.biz.req.pem''. We can leave out terms like ''-newkey rsa:2048'' and ''-days 370'' since we've put that in the configuration file. And naturally you're free to choose your own names for the keys.