OpenSSL Certificate Authority - Revision history

Jeff at 03:20, 6 September 2009

Jeff — Sun, 06 Sep 2009 03:20:02 GMT

←Older revision		Revision as of 03:20, 6 September 2009
Line 157:		Line 157:
	openssl x509 -text -in new.crt		openssl x509 -text -in new.crt
	</pre>		</pre>
		+
		+	----
		+	[[User:Jeff\|Jeff]]

Jeff: NotesOnOpenSSL moved to OpenSSL Certificate Authority

Jeff — Thu, 25 Jun 2009 01:58:57 GMT

NotesOnOpenSSL moved to OpenSSL Certificate Authority

←Older revision

Revision as of 01:58, 25 June 2009

Jeff at 01:56, 25 June 2009

Jeff — Thu, 25 Jun 2009 01:56:03 GMT

←Older revision	Revision as of 01:56, 25 June 2009
Line 1:	Line 1:
	+	To generate a private key, you don't need a config file. Just execute the following.

	+	<pre>
	+	openssl genrsa -out example.key 1024
	+	</pre>
	+
	+	You may not wish to be prompted for a passphrase, because then you will have to enter the passphrase every time you use the resulting key (like restarting httpd). In this case, indlude the <tt>-nodes</tt> flag before the number of bits.
	+
	+	Set up the directory to hold the Certificate Authority. <tt>$CA_ROOT</tt> can be something like <tt>/opt/ca</tt>.
	+
	+	<pre>
	+	mkdir -m 0700 -p $CA_ROOT/{certs,crl,csr,private}
	+	touch $CA_ROOT/index.txt
	+	echo 01 > $CA_ROOT/serial
	+	</pre>
	+
	+	Here is a functional <tt>openssl.cnf</tt> for a Certificate Authority.
	+
	+	<pre>
	+	[ ca ]
	+	default_ca = rootca
	+
	+	[ rootca ]
	+	dir = /opt/ca
	+	certificate = $dir/private/ca.crt
	+	private_key = $dir/private/ca.key
	+	database = $dir/index.txt
	+	serial = $dir/serial
	+	new_certs_dir = $dir/certs
	+
	+	default_crl_days = 7
	+	default_days = 365
	+	default_md = md5
	+	crlDistributionPoints = URI:http://sslcert.example.com/example.crl
	+
	+	policy = rootca_policy
	+	x509_extensions = certificate_extensions
	+
	+	copy_extensions = copy
	+
	+	[ rootca_policy ]
	+	commonName = supplied
	+	organizationName = supplied
	+	organizationalUnitName = optional
	+	countryName = supplied
	+	stateOrProvinceName = supplied
	+	localityName = supplied
	+	emailAddress = supplied
	+
	+	[ certificate_extensions ]
	+	basicConstraints = CA:false
	+
	+	[ req ]
	+	default_bits = 4096
	+	default_keyfile = /opt/ca/private/ca.key
	+	default_md = md5
	+
	+	prompt = no
	+	distinguished_name = root_ca_distinguished_name
	+	x509_extensions = root_ca_extensions
	+
	+	[ root_ca_distinguished_name ]
	+	commonName = Example Corp., Inc.
	+	organizationName = Certificate Authority
	+	countryName = US
	+	stateOrProvinceName = California
	+	localityName = Los Angeles
	+	emailAddress = root@example.com
	+
	+	[ root_ca_extensions ]
	+	basicConstraints = CA:true
	+	</pre>
	+
	+	To generate the CA Certificate, you can either generate the private key at the same time or ahead of time using the instructions above. If the private key is already generated, use the following:
	+
	+	<pre>
	+	openssl req -x509 -config openssl.cnf -key ca.key -out ca.crt
	+	</pre>
	+
	+	Or to generate the key at the same time use:
	+
	+	<pre>
	+	openssl req -x509 -config openssl.cnf -newkey rsa:1024 -keyout ca.key -out ca.crt
	+	</pre>
	+
	+	And if you just want to generate a self-signed key for use on a web server or similar, make sure <tt>basicConstraints</tt> is set to <tt>CA:false</tt>. You can do this by the setting for X.509 extensions in the <tt>req</tt> section of the conf file. Either point <tt>x509_extensions</tt> at the <tt>certificate_extensions</tt> section where CA is false, or change <tt>basicConstraints</tt> under the <tt>root_ca_extensions</tt> to <tt>CA:false</tt>.
	+
	+	The above should be maintained on the host where the CA resides. It is best to make a new config file for every key pair you need to generate. Create the key on the host where the service it will be used with is running, in a directory related to the service. For example, make a new config file to generate a <tt>key</tt> and <tt>csr</tt> for a web server on that web server host, in a directory associated with the web server's configuration, such as <tt>/etc/httpd/ssl</tt> or similar. The logic behind this is that you want to minimize any risk associated with exposing the private key to the network. Therefore, generate the private <tt>key</tt> followed by the <tt>csr</tt> on the server where it will be used. Here is an <tt>openssl.cnf</tt> for creating a Request with Subject Alternative Names.
	+
	+	<pre>
	+	#oid_section = new_oids
	+	#
	+	#[ new_oids ]
	+	## RFC 3920 section 5.1.1 defines this OID
	+	#xmppAddr = 1.3.6.1.5.5.7.8.5
	+
	+	[ req ]
	+	default_bits = 4096
	+	default_keyfile = san-example.key
	+	distinguished_name = distinguished_name
	+	req_extensions = v3_extensions
	+	x509_extensions = v3_extensions
	+
	+	# don't ask about the DN
	+	prompt = no
	+
	+	[ distinguished_name ]
	+	countryName = US
	+	stateOrProvinceName = California
	+	localityName = Los Angeles
	+	organizationName = Example Corp., Inc.
	+	commonName = example.com
	+	emailAddress = root@example.com
	+
	+	[ v3_extensions ]
	+	# for certificate requests (req_extensions)
	+	# and self-signed certificates (x509_extensions)
	+	basicConstraints = CA:FALSE
	+	keyUsage = digitalSignature,keyEncipherment
	+	subjectAltName = @subject_alternative_name
	+
	+	[ subject_alternative_name ]
	+	email.0 = root@example.com
	+	DNS.1 = www.example.com
	+	URI.2 = URI:http://www.example.com/
	+	IP.3 = 192.168.1.1
	+	IP.4 = fe80::1
	+	</pre>
	+
	+	To generate the Certificate Signing Request, use the following command.
	+
	+	<pre>
	+	openssl req -nodes -config ./openssl.cnf -newkey rsa:4096 -keyout new.key -out new.csr
	+	</pre>
	+
	+	The above command generates the private key and the request at the same time. If you have already generated the key, replace <tt>-newkey</tt> with <tt>-key</tt>. If you want the private key to be password protected, drop the <tt>-nodes</tt> flag.
	+
	+	Once the request is generated, it can be signed by the CA. Use the following command to do so.
	+
	+	<pre>
	+	openssl ca -config /opt/ca/openssl.cnf -in new.csr
	+	</pre>
	+
	+	You can add <tt>-days NUM</tt> to change the default expiration of the generated certificate. This will dump the certificate to stdout, and save it as a file in the directory specified as <tt>new_cert_dir</tt>, named <tt>SERIAL.pem</tt>, where the next <tt>SERIAL</tt> is specified in the serial file. Basically, it will be the largest number in the directory. Send this back to the system that is making the request.
	+
	+	You should be aware that Keys are private and that Requests (unsigned) and Certificates (signed) are pubic, so it is ok to copy the <tt>.csr</tt> and <tt>.crt</tt> over the network in the clear, but never send the <tt>*.key</tt> out.
	+
	+	You can read the data in the request and the certificate, to make sure they were generated correctly or help you identify them. To read the request, use the following:
	+
	+	<pre>
	+	openssl req -text -in new.csr
	+	</pre>
	+
	+	And to read the certificate, the syntax is nearly identical:
	+
	+	<pre>
	+	openssl x509 -text -in new.crt
	+	</pre>

Jeff at 01:42, 25 June 2009

Jeff — Thu, 25 Jun 2009 01:42:50 GMT

←Older revision		Revision as of 01:42, 25 June 2009
Line 1:		Line 1:
-	~~To generate a private key, you don't need a config file. Just execute the following.~~

-	~~<pre>~~
-	~~openssl genrsa -out example.key 1024~~
-	~~</pre>~~
-
-	You may not wish to be prompted for a passphrase, because then you will have to enter the passphrase every time you use the resulting key (like restarting httpd). In this case, indlude the <tt>-nodes</tt> flag before the number of bits.
-
-	~~Set up the directory to hold the Certificate Authority. <tt>$CA_ROOT</tt> can be something like <tt>/opt/ca</tt>.~~
-
-	~~<pre>~~
-	~~mkdir -m 0700 -p $CA_ROOT/{certs,crl,csr,private}~~
-	~~touch $CA_ROOT/index.txt~~
-	~~echo 01 > $CA_ROOT/serial~~
-	~~</pre>~~
-
-	~~Here is a functional <tt>openssl.cnf</tt> for a Certificate Authority.~~
-
-	~~<pre>~~
-	~~[ ca ]~~
-	~~default_ca = rootca~~
-
-	~~[ rootca ]~~
-	~~dir = /opt/ca~~
-	~~certificate = $dir/private/ca.crt~~
-	~~private_key = $dir/private/ca.key~~
-	~~database = $dir/index.txt~~
-	~~serial = $dir/serial~~
-	~~new_certs_dir = $dir/certs~~
-
-	~~default_crl_days = 7~~
-	~~default_days = 365~~
-	~~default_md = md5~~
-	~~crlDistributionPoints = URI:http://sslcert.example.com/example.crl~~
-
-	~~policy = rootca_policy~~
-	~~x509_extensions = certificate_extensions~~
-
-	~~copy_extensions = copy~~
-
-	~~[ rootca_policy ]~~
-	~~commonName = supplied~~
-	~~organizationName = supplied~~
-	~~organizationalUnitName = optional~~
-	~~countryName = supplied~~
-	~~stateOrProvinceName = supplied~~
-	~~localityName = supplied~~
-	~~emailAddress = supplied~~
-
-	~~[ certificate_extensions ]~~
-	~~basicConstraints = CA:false~~
-
-	~~[ req ]~~
-	~~default_bits = 4096~~
-	~~default_keyfile = /opt/ca/private/ca.key~~
-	~~default_md = md5~~
-
-	~~prompt = no~~
-	~~distinguished_name = root_ca_distinguished_name~~
-	~~x509_extensions = root_ca_extensions~~
-
-	~~[ root_ca_distinguished_name ]~~
-	~~commonName = Example Corp., Inc.~~
-	~~organizationName = Certificate Authority~~
-	~~countryName = US~~
-	~~stateOrProvinceName = California~~
-	~~localityName = Los Angeles~~
-	~~emailAddress = root@example.com~~
-
-	~~[ root_ca_extensions ]~~
-	~~basicConstraints = CA:true~~
-	~~</pre>~~
-
-	~~To generate the CA Certificate, you can either generate the private key at the same time or ahead of time using the instructions above. If the private key is already generated, use the following:~~
-
-	~~<pre>~~
-	~~openssl req -x509 -config openssl.cnf -key ca.key -out ca.crt~~
-	~~</pre>~~
-
-	~~Or to generate the key at the same time use:~~
-
-	~~<pre>~~
-	~~openssl req -x509 -config openssl.cnf -newkey rsa:1024 -keyout ca.key -out ca.crt~~
-	~~</pre>~~
-
-	And if you just want to generate a self-signed key for use on a web server or similar, make sure <tt>basicConstraints</tt> is set to <tt>CA:false</tt>. You can do this by the setting for X.509 extensions in the <tt>req</tt> section of the conf file. Either point <tt>x509_extensions</tt> at the <tt>certificate_extensions</tt> section where CA is false, or change <tt>basicConstraints</tt> under the <tt>root_ca_extensions</tt> to <tt>CA:false</tt>.
-
-	The above should be maintained on the host where the CA resides. It is best to make a new config file for every key pair you need to generate. Create the key on the host where the service it will be used with is running, in a directory related to the service. For example, make a new config file to generate a <tt>key</tt> and <tt>csr</tt> for a web server on that web server host, in a directory associated with the web server's configuration, such as <tt>/etc/httpd/ssl</tt> or similar. The logic behind this is that you want to minimize any risk associated with exposing the private key to the network. Therefore, generate the private <tt>key</tt> followed by the <tt>csr</tt> on the server where it will be used. Here is an <tt>openssl.cnf</tt> for creating a Request with Subject Alternative Names.
-
-	~~<pre>~~
-	~~#oid_section = new_oids~~
-	#
-	~~#[ new_oids ]~~
-	~~## RFC 3920 section 5.1.1 defines this OID~~
-	~~#xmppAddr = 1.3.6.1.5.5.7.8.5~~
-
-	~~[ req ]~~
-	~~default_bits = 4096~~
-	~~default_keyfile = san-example.key~~
-	~~distinguished_name = distinguished_name~~
-	~~req_extensions = v3_extensions~~
-	~~x509_extensions = v3_extensions~~
-
-	~~# don't ask about the DN~~
-	~~prompt = no~~
-
-	~~[ distinguished_name ]~~
-	~~countryName = US~~
-	~~stateOrProvinceName = California~~
-	~~localityName = Los Angeles~~
-	~~organizationName = Example Corp., Inc.~~
-	~~commonName = example.com~~
-	~~emailAddress = root@example.com~~
-
-	~~[ v3_extensions ]~~
-	~~# for certificate requests (req_extensions)~~
-	~~# and self-signed certificates (x509_extensions)~~
-	~~basicConstraints = CA:FALSE~~
-	~~keyUsage = digitalSignature,keyEncipherment~~
-	~~subjectAltName = @subject_alternative_name~~
-
-	~~[ subject_alternative_name ]~~
-	~~email.0 = root@example.com~~
-	~~DNS.1 = www.example.com~~
-	~~URI.2 = URI:http://www.example.com/~~
-	~~IP.3 = 192.168.1.1~~
-	~~IP.4 = fe80::1~~
-	~~</pre>~~
-
-	~~To generate the Certificate Signing Request, use the following command.~~
-
-	~~<pre>~~
-	~~openssl req -nodes -config ./openssl.cnf -newkey rsa:4096 -keyout new.key -out new.csr~~
-	~~</pre>~~
-
-	The above command generates the private key and the request at the same time. If you have already generated the key, replace <tt>-newkey</tt> with <tt>-key</tt>. If you want the private key to be password protected, drop the <tt>-nodes</tt> flag.
-
-	~~Once the request is generated, it can be signed by the CA. Use the following command to do so.~~
-
-	~~<pre>~~
-	~~openssl ca -config /opt/ca/openssl.cnf -in new.csr~~
-	~~</pre>~~
-
-	You can add <tt>-days NUM</tt> to change the default expiration of the generated certificate. This will dump the certificate to stdout, and save it as a file in the directory specified as <tt>new_cert_dir</tt>, named <tt>SERIAL.pem</tt>, where the next <tt>SERIAL</tt> is specified in the serial file. Basically, it will be the largest number in the directory. Send this back to the system that is making the request.
-
-	You should be aware that Keys are private and that Requests (unsigned) and Certificates (signed) are pubic, so it is ok to copy the <tt>.csr</tt> and <tt>.crt</tt> over the network in the clear, but never send the <tt>*.key</tt> out.
-
-	~~You can read the data in the request and the certificate, to make sure they were generated correctly or help you identify them. To read the request, use the following:~~
-
-	~~<pre>~~
-	~~openssl req -text -in new.csr~~
-	~~</pre>~~
-
-	~~And to read the certificate, the syntax is nearly identical:~~
-
-	~~<pre>~~
-	~~openssl x509 -text -in new.crt~~
-	~~</pre>~~

Jeff at 07:49, 24 June 2009

Jeff — Wed, 24 Jun 2009 07:49:03 GMT

←Older revision		Revision as of 07:49, 24 June 2009
Line 5:		Line 5:
	</pre>		</pre>

-	You may not wish to be prompted for a passphrase, because then you will have to enter the passphrase every time you use the resulting key (like restarting httpd). In this case, indlude the -nodes flag before the number of bits.	+	You may not wish to be prompted for a passphrase, because then you will have to enter the passphrase every time you use the resulting key (like restarting httpd). In this case, indlude the <tt>-nodes</tt> flag before the number of bits.

-	Set up the directory to hold the Certificate Authority. $CA_ROOT can be something like /opt/ca.	+	Set up the directory to hold the Certificate Authority. <tt>$CA_ROOT</tt> can be something like <tt>/opt/ca</tt>.

	<pre>		<pre>
Line 15:		Line 15:
	</pre>		</pre>

-	Here is a functional openssl.cnf for a Certificate Authority.	+	Here is a functional <tt>openssl.cnf</tt> for a Certificate Authority.

	<pre>		<pre>
Line 84:		Line 84:
	</pre>		</pre>

-	And if you just want to generate a self-signed key for use on a web server or similar, make sure basicConstraints is set to CA:false. You can do this by the setting for X.509 extensions in the req section of the conf file. Either point x509_extensions at the certificate_extensions section where CA is false, or change basicConstraints under the root_ca_extensions to CA:false.	+	And if you just want to generate a self-signed key for use on a web server or similar, make sure <tt>basicConstraints</tt> is set to <tt>CA:false</tt>. You can do this by the setting for X.509 extensions in the <tt>req</tt> section of the conf file. Either point <tt>x509_extensions</tt> at the <tt>certificate_extensions</tt> section where CA is false, or change <tt>basicConstraints</tt> under the <tt>root_ca_extensions</tt> to <tt>CA:false</tt>.

-	The above should be maintained on the host where the CA resides. It is best to make a new config file for every key pair you need to generate. Create the key on the host where the service it will be used with is running, in a directory related to the service. For example, make a new config file to generate a key and csr for a web server on that web server host, in a directory associated with the web server's configuration, such as /etc/httpd/ssl or similar. The logic behind this is that you want to minimize any risk associated with exposing the private key to the network. Therefore, generate the private key followed by the csr on the server where it will be used. Here is an openssl.cnf for creating a Request with Subject Alternative Names.	+	The above should be maintained on the host where the CA resides. It is best to make a new config file for every key pair you need to generate. Create the key on the host where the service it will be used with is running, in a directory related to the service. For example, make a new config file to generate a <tt>key</tt> and <tt>csr</tt> for a web server on that web server host, in a directory associated with the web server's configuration, such as <tt>/etc/httpd/ssl</tt> or similar. The logic behind this is that you want to minimize any risk associated with exposing the private key to the network. Therefore, generate the private <tt>key</tt> followed by the <tt>csr</tt> on the server where it will be used. Here is an <tt>openssl.cnf</tt> for creating a Request with Subject Alternative Names.

	<pre>		<pre>
Line 134:		Line 134:
	</pre>		</pre>

-	The above command generates the private key and the request at the same time. If you have already generated the key, replace -newkey with -key. If you want the private key to be password protected, drop the -nodes flag.	+	The above command generates the private key and the request at the same time. If you have already generated the key, replace <tt>-newkey</tt> with <tt>-key</tt>. If you want the private key to be password protected, drop the <tt>-nodes</tt> flag.

	Once the request is generated, it can be signed by the CA. Use the following command to do so.		Once the request is generated, it can be signed by the CA. Use the following command to do so.
Line 142:		Line 142:
	</pre>		</pre>

-	You can add -days NUM to change the default expiration of the generated certificate. This will dump the certificate to stdout, and save it as a file in the directory specified as new_cert_dir, named SERIAL.pem, where the next SERIAL is specified in the serial file. Basically, it will be the largest number in the directory. Send this back to the system that is making the request.	+	You can add <tt>-days NUM</tt> to change the default expiration of the generated certificate. This will dump the certificate to stdout, and save it as a file in the directory specified as <tt>new_cert_dir</tt>, named <tt>SERIAL.pem</tt>, where the next <tt>SERIAL</tt> is specified in the serial file. Basically, it will be the largest number in the directory. Send this back to the system that is making the request.

-	You should be aware that Keys are private and that Requests (unsigned) and Certificates (signed) are pubic, so it is ok to copy the .csr and .crt over the network in the clear, but never send the *.key out.	+	You should be aware that Keys are private and that Requests (unsigned) and Certificates (signed) are pubic, so it is ok to copy the <tt>.csr</tt> and <tt>.crt</tt> over the network in the clear, but never send the <tt>*.key</tt> out.

	You can read the data in the request and the certificate, to make sure they were generated correctly or help you identify them. To read the request, use the following:		You can read the data in the request and the certificate, to make sure they were generated correctly or help you identify them. To read the request, use the following:

Jeff at 05:47, 16 June 2009

Jeff — Tue, 16 Jun 2009 05:47:58 GMT

←Older revision		Revision as of 05:47, 16 June 2009
Line 145:		Line 145:

	You should be aware that Keys are private and that Requests (unsigned) and Certificates (signed) are pubic, so it is ok to copy the .csr and .crt over the network in the clear, but never send the *.key out.		You should be aware that Keys are private and that Requests (unsigned) and Certificates (signed) are pubic, so it is ok to copy the .csr and .crt over the network in the clear, but never send the *.key out.
		+
		+	You can read the data in the request and the certificate, to make sure they were generated correctly or help you identify them. To read the request, use the following:
		+
		+	<pre>
		+	openssl req -text -in new.csr
		+	</pre>
		+
		+	And to read the certificate, the syntax is nearly identical:
		+
		+	<pre>
		+	openssl x509 -text -in new.crt
		+	</pre>

Jeff at 05:38, 16 June 2009

Jeff — Tue, 16 Jun 2009 05:38:02 GMT

←Older revision		Revision as of 05:38, 16 June 2009
Line 9:		Line 9:
	Set up the directory to hold the Certificate Authority. $CA_ROOT can be something like /opt/ca.		Set up the directory to hold the Certificate Authority. $CA_ROOT can be something like /opt/ca.

-	<~~source lang="sh"~~>	+	<pre>
	mkdir -m 0700 -p $CA_ROOT/{certs,crl,csr,private}		mkdir -m 0700 -p $CA_ROOT/{certs,crl,csr,private}
	touch $CA_ROOT/index.txt		touch $CA_ROOT/index.txt
	echo 01 > $CA_ROOT/serial		echo 01 > $CA_ROOT/serial
-	</~~source~~>	+	</pre>

	Here is a functional openssl.cnf for a Certificate Authority.		Here is a functional openssl.cnf for a Certificate Authority.

Jeff at 05:36, 16 June 2009

Jeff — Tue, 16 Jun 2009 05:36:29 GMT

←Older revision		Revision as of 05:36, 16 June 2009
Line 9:		Line 9:
	Set up the directory to hold the Certificate Authority. $CA_ROOT can be something like /opt/ca.		Set up the directory to hold the Certificate Authority. $CA_ROOT can be something like /opt/ca.

-	<~~pre~~>	+	<source lang="sh">
	mkdir -m 0700 -p $CA_ROOT/{certs,crl,csr,private}		mkdir -m 0700 -p $CA_ROOT/{certs,crl,csr,private}
	touch $CA_ROOT/index.txt		touch $CA_ROOT/index.txt
	echo 01 > $CA_ROOT/serial		echo 01 > $CA_ROOT/serial
-	</~~pre~~>	+	</source>

	Here is a functional openssl.cnf for a Certificate Authority.		Here is a functional openssl.cnf for a Certificate Authority.

Jeff at 19:15, 15 June 2009

Jeff — Mon, 15 Jun 2009 19:15:31 GMT

←Older revision		Revision as of 19:15, 15 June 2009
Line 1:		Line 1:
	To generate a private key, you don't need a config file. Just execute the following.		To generate a private key, you don't need a config file. Just execute the following.

		+	<pre>
	openssl genrsa -out example.key 1024		openssl genrsa -out example.key 1024
		+	</pre>

	You may not wish to be prompted for a passphrase, because then you will have to enter the passphrase every time you use the resulting key (like restarting httpd). In this case, indlude the -nodes flag before the number of bits.		You may not wish to be prompted for a passphrase, because then you will have to enter the passphrase every time you use the resulting key (like restarting httpd). In this case, indlude the -nodes flag before the number of bits.

Jeff at 19:13, 15 June 2009

Jeff — Mon, 15 Jun 2009 19:13:58 GMT

←Older revision		Revision as of 19:13, 15 June 2009
Line 7:		Line 7:
	Set up the directory to hold the Certificate Authority. $CA_ROOT can be something like /opt/ca.		Set up the directory to hold the Certificate Authority. $CA_ROOT can be something like /opt/ca.

		+	<pre>
	mkdir -m 0700 -p $CA_ROOT/{certs,crl,csr,private}		mkdir -m 0700 -p $CA_ROOT/{certs,crl,csr,private}
	touch $CA_ROOT/index.txt		touch $CA_ROOT/index.txt
	echo 01 > $CA_ROOT/serial		echo 01 > $CA_ROOT/serial
		+	</pre>

	Here is a functional openssl.cnf for a Certificate Authority.		Here is a functional openssl.cnf for a Certificate Authority.

		+	<pre>
	[ ca ]		[ ca ]
	default_ca = rootca		default_ca = rootca
Line 65:		Line 68:
	[ root_ca_extensions ]		[ root_ca_extensions ]
	basicConstraints = CA:true		basicConstraints = CA:true
		+	</pre>

	To generate the CA Certificate, you can either generate the private key at the same time or ahead of time using the instructions above. If the private key is already generated, use the following:		To generate the CA Certificate, you can either generate the private key at the same time or ahead of time using the instructions above. If the private key is already generated, use the following:

		+	<pre>
	openssl req -x509 -config openssl.cnf -key ca.key -out ca.crt		openssl req -x509 -config openssl.cnf -key ca.key -out ca.crt
		+	</pre>

	Or to generate the key at the same time use:		Or to generate the key at the same time use:

		+	<pre>
	openssl req -x509 -config openssl.cnf -newkey rsa:1024 -keyout ca.key -out ca.crt		openssl req -x509 -config openssl.cnf -newkey rsa:1024 -keyout ca.key -out ca.crt
		+	</pre>

	And if you just want to generate a self-signed key for use on a web server or similar, make sure basicConstraints is set to CA:false. You can do this by the setting for X.509 extensions in the req section of the conf file. Either point x509_extensions at the certificate_extensions section where CA is false, or change basicConstraints under the root_ca_extensions to CA:false.		And if you just want to generate a self-signed key for use on a web server or similar, make sure basicConstraints is set to CA:false. You can do this by the setting for X.509 extensions in the req section of the conf file. Either point x509_extensions at the certificate_extensions section where CA is false, or change basicConstraints under the root_ca_extensions to CA:false.
Line 78:		Line 86:
	The above should be maintained on the host where the CA resides. It is best to make a new config file for every key pair you need to generate. Create the key on the host where the service it will be used with is running, in a directory related to the service. For example, make a new config file to generate a key and csr for a web server on that web server host, in a directory associated with the web server's configuration, such as /etc/httpd/ssl or similar. The logic behind this is that you want to minimize any risk associated with exposing the private key to the network. Therefore, generate the private key followed by the csr on the server where it will be used. Here is an openssl.cnf for creating a Request with Subject Alternative Names.		The above should be maintained on the host where the CA resides. It is best to make a new config file for every key pair you need to generate. Create the key on the host where the service it will be used with is running, in a directory related to the service. For example, make a new config file to generate a key and csr for a web server on that web server host, in a directory associated with the web server's configuration, such as /etc/httpd/ssl or similar. The logic behind this is that you want to minimize any risk associated with exposing the private key to the network. Therefore, generate the private key followed by the csr on the server where it will be used. Here is an openssl.cnf for creating a Request with Subject Alternative Names.

		+	<pre>
	#oid_section = new_oids		#oid_section = new_oids
	#		#
Line 115:		Line 124:
	IP.3 = 192.168.1.1		IP.3 = 192.168.1.1
	IP.4 = fe80::1		IP.4 = fe80::1
		+	</pre>

	To generate the Certificate Signing Request, use the following command.		To generate the Certificate Signing Request, use the following command.

		+	<pre>
	openssl req -nodes -config ./openssl.cnf -newkey rsa:4096 -keyout new.key -out new.csr		openssl req -nodes -config ./openssl.cnf -newkey rsa:4096 -keyout new.key -out new.csr
		+	</pre>

	The above command generates the private key and the request at the same time. If you have already generated the key, replace -newkey with -key. If you want the private key to be password protected, drop the -nodes flag.		The above command generates the private key and the request at the same time. If you have already generated the key, replace -newkey with -key. If you want the private key to be password protected, drop the -nodes flag.
Line 124:		Line 136:
	Once the request is generated, it can be signed by the CA. Use the following command to do so.		Once the request is generated, it can be signed by the CA. Use the following command to do so.

		+	<pre>
	openssl ca -config /opt/ca/openssl.cnf -in new.csr		openssl ca -config /opt/ca/openssl.cnf -in new.csr
		+	</pre>

	You can add -days NUM to change the default expiration of the generated certificate. This will dump the certificate to stdout, and save it as a file in the directory specified as new_cert_dir, named SERIAL.pem, where the next SERIAL is specified in the serial file. Basically, it will be the largest number in the directory. Send this back to the system that is making the request.		You can add -days NUM to change the default expiration of the generated certificate. This will dump the certificate to stdout, and save it as a file in the directory specified as new_cert_dir, named SERIAL.pem, where the next SERIAL is specified in the serial file. Basically, it will be the largest number in the directory. Send this back to the system that is making the request.

	You should be aware that Keys are private and that Requests (unsigned) and Certificates (signed) are pubic, so it is ok to copy the .csr and .crt over the network in the clear, but never send the *.key out.		You should be aware that Keys are private and that Requests (unsigned) and Certificates (signed) are pubic, so it is ok to copy the .csr and .crt over the network in the clear, but never send the *.key out.