Certificate fundamentals - Revision history

Saruman!: /* We've got the CA certificate, now what? */

2016-10-29T20:25:09Z

We've got the CA certificate, now what?

← Older revision		Revision as of 20:25, 29 October 2016
Line 137:		Line 137:
	To create a public CA certificate in .crt format you can issue the following command:		To create a public CA certificate in .crt format you can issue the following command:
	openssl x509 -outform der -in cacert.pem -out cacert.crt		openssl x509 -outform der -in cacert.pem -out cacert.crt
	By the way, it's usually better to distribute the public certificate with a more recognizable file name, such as ''saruman.~~biz~~.crt''		By the way, it's usually better to distribute the public certificate with a more recognizable file name, such as ''saruman.bizRootCA.crt''

Saruman!: /* Creating the CA root certificate key pair */ added passphrase

2016-10-29T20:23:57Z

Creating the CA root certificate key pair: added passphrase

← Older revision		Revision as of 20:23, 29 October 2016
Line 114:		Line 114:
	Note from the last command above, that this certificate is obviously a root certificate: it can verify the signature of everything but the kitchen sink.		Note from the last command above, that this certificate is obviously a root certificate: it can verify the signature of everything but the kitchen sink.

	In the same manner you can inspect your private key:		In the same manner you can inspect your private key - note that you'll have to provide the passphrase to complete this command:
	openssl rsa -in private/cakey.pem -noout -text		openssl rsa -in private/cakey.pem -noout -text

Line 121:		Line 121:
	openssl x509 -in cacert.pem -noout -modulus \| openssl md5		openssl x509 -in cacert.pem -noout -modulus \| openssl md5
	openssl rsa -in private/cakey.pem -noout -modulus \| openssl md5		openssl rsa -in private/cakey.pem -noout -modulus \| openssl md5
	And then compare these really shorter numbers. Both commands will output something like:		And then compare these really shorter numbers (and again, you'll have to provide the passphrase to read the private key). Both commands will output something like:
	(stdin)= 96a281eca852b794a907186a9703ddf4		(stdin)= 96a281eca852b794a907186a9703ddf4
	With overwhelming probability they will differ if the keys are different.		With overwhelming probability they will differ if the keys are different.

Saruman!: /* We've got the CA certificate, now what? */

2016-10-29T20:21:48Z

We've got the CA certificate, now what?

← Older revision		Revision as of 20:21, 29 October 2016
Line 130:		Line 130:
	* sign certificates for our own use;		* sign certificates for our own use;
	* distribute the public CA certificate to every machine/person that may need to verify certificates that we've signed.		* distribute the public CA certificate to every machine/person that may need to verify certificates that we've signed.
	The first means we've got to keep a copy of the private key file in some other, safe location, and we've got to secure the private key on the server where it sits - both the machine and the file. It might even be wise to remove the private key, and keep it on a USB stick, and only read it when signing certificates.		The first means we've got to keep a copy of the private key file in some other, safe location, and we've got to secure the private key on the server where it sits - both the machine and the file. At the very least, you have to make sure the private key is owned by root or an administrative account, and is ''not'' world-readable. It might even be wise to remove the private key altogether, and keep it on a USB stick, and only read it when signing certificates.

	The second thing means we've got to generate keys for SSL and TLS connections, just as we need them. This is covered in our [[Creating digital certificates with our root certificate \| creating digital certificates]] section.		The second thing means we've got to generate keys for SSL and TLS connections, just as we need them. This is covered in our [[Creating digital certificates with our root certificate \| creating digital certificates]] section.

	The last point means we need to send out our public CA certificate. In some cases, you can provide others with your ''.pem'' file, but in other cases you're better off providing a simpler ''.crt'' file. The difference is explained nicely at the [http://info.ssl.com/article.aspx?id=12149 ssl.com site]		The last point means we need to send out our public CA certificate. In some cases, you can provide others with your ''.pem'' file, but in other cases you're better off providing a simpler ''.crt'' file. The difference is explained nicely at the [http://info.ssl.com/article.aspx?id=12149 ssl.com site]
	To create a public CA certificate in .crt format you can issue the following command:		To create a public CA certificate in .crt format you can issue the following command:
	openssl x509 -outform der -in cacert.pem -out cacert.crt		openssl x509 -outform der -in cacert.pem -out cacert.crt
	By the way, it's usually better to distribute the public certificate with a more recognizable file name, such as ''saruman.biz.crt''		By the way, it's usually better to distribute the public certificate with a more recognizable file name, such as ''saruman.biz.crt''

Saruman!: corrected directory name - /etc/ssl not /etc/openssl

2016-10-29T20:12:05Z

corrected directory name - /etc/ssl not /etc/openssl

← Older revision		Revision as of 20:12, 29 October 2016
Line 99:		Line 99:

	For the next set of questions, you probably have filled in some of the defaults. If you want to leave some entry blank, fill in a period ('''.'''). You'll have to provide the country code, province or state, locality (like city; Saruman.biz leaves this empty), Organization Name, Organizational Unit name (again, empty), and finally the Common Name. This last question is pretty important: the name you put in here is the name under which your CA will go for the next 15 years!! So don't put in a "funny" name, a bland name, or whatever. We put in "Saruman.biz Root CA", somewhat like official root CA's like "Equifax Secure Global eBusiness CA-1" or "Macao Post eSignTrust Root Certification Authority". The script also asks for an email address, which you may or may not provide, a challenge password, and an "optional company name", both of which you can leave blank because we're not sending a certificate signing request out to someone else, but signing it ourselves.<br>		For the next set of questions, you probably have filled in some of the defaults. If you want to leave some entry blank, fill in a period ('''.'''). You'll have to provide the country code, province or state, locality (like city; Saruman.biz leaves this empty), Organization Name, Organizational Unit name (again, empty), and finally the Common Name. This last question is pretty important: the name you put in here is the name under which your CA will go for the next 15 years!! So don't put in a "funny" name, a bland name, or whatever. We put in "Saruman.biz Root CA", somewhat like official root CA's like "Equifax Secure Global eBusiness CA-1" or "Macao Post eSignTrust Root Certification Authority". The script also asks for an email address, which you may or may not provide, a challenge password, and an "optional company name", both of which you can leave blank because we're not sending a certificate signing request out to someone else, but signing it ourselves.<br>
	Having provided this information, we've actually already created one half of the key pair, namely the private key. It'll be ''/etc/~~openssl~~/ca/private/ca.pem'', and is protected by our chosen very strong password. However, we now need the public key, self-signed with the private key.		Having provided this information, we've actually already created one half of the key pair, namely the private key. It'll be ''/etc/ssl/ca/private/ca.pem'', and is protected by our chosen very strong password. However, we now need the public key, self-signed with the private key.

	The next step in our CA creation process thus ''again'' asks for the passphrase. Since this is the second step in a two-step process, we again put in the passphrase we've already provided. However, now the shellscript uses this to unlock the private key we've (already) created, and then use it to sign the public key we're now creating. However, the passphrase is ''all'' that it asks. It now generates a signing request (''/etc/~~openssl~~/ca/careq.pem''), then uses the private key to sign it, and then generate the public key, to be found in ''/etc/~~openssl~~/ca/cacert.pem''. You can remove ''careq.pem'' after you've inspected the ''cacert.pem''.		The next step in our CA creation process thus ''again'' asks for the passphrase. Since this is the second step in a two-step process, we again put in the passphrase we've already provided. However, now the shellscript uses this to unlock the private key we've (already) created, and then use it to sign the public key we're now creating. However, the passphrase is ''all'' that it asks. It now generates a signing request (''/etc/ssl/ca/careq.pem''), then uses the private key to sign it, and then generate the public key, to be found in ''/etc/ssl/ca/cacert.pem''. You can remove ''careq.pem'' after you've inspected the ''cacert.pem''.

	So now we've got two root certificates, namely		So now we've got two root certificates, namely
	* '''private''' key ''/etc/~~openssl~~/ca/private/cakey.pem'', and		* '''private''' key ''/etc/ssl/ca/private/cakey.pem'', and
	* '''public''' key ''/etc/~~openssl~~/ca/cacert.pem''.		* '''public''' key ''/etc/ssl/ca/cacert.pem''.
	NEVER send your private key out to ANYONE! Protect that key, and its passphrase, with your life. If you lose the file, lose the passphrase, or the key gets compromised (lost to an unknown party) then you've got to replace your root certificates AND you'll have to re-issue ALL certificates that you've ever signed (we're not going into certificate revocation here).		NEVER send your private key out to ANYONE! Protect that key, and its passphrase, with your life. If you lose the file, lose the passphrase, or the key gets compromised (lost to an unknown party) then you've got to replace your root certificates AND you'll have to re-issue ALL certificates that you've ever signed (we're not going into certificate revocation here).

	You can inspect your certificates (when you're in directory ''/etc/~~openssl~~/ca'') with commands like this:		You can inspect your certificates (when you're in directory ''/etc/ssl/ca'') with commands like this:
	openssl x509 -in cacert.pem -noout -text		openssl x509 -in cacert.pem -noout -text
	openssl x509 -in cacert.pem -noout -dates		openssl x509 -in cacert.pem -noout -dates

Saruman!: /* We've got the CA certificate, now what? */ added crt conversion

2016-10-29T20:06:52Z

We've got the CA certificate, now what?: added crt conversion

← Older revision		Revision as of 20:06, 29 October 2016
Line 126:		Line 126:

	===We've got the CA certificate, now what?===		===We've got the CA certificate, now what?===
	With the root CA certificates available to us, we've got ~~two~~ things to do:		With the root CA certificates available to us, we've got the following things to do:
	* guard very carefully the public and (especially) the private key file		* guard very carefully the public and (especially) the private key file;
	* sign certificates for our own use		* sign certificates for our own use;
			* distribute the public CA certificate to every machine/person that may need to verify certificates that we've signed.
	The first means we've got to keep a copy of the private key file in some other, safe location, and we've got to secure the private key on the server where it sits - both the machine and the file. It might even be wise to remove the private key, and keep it on a USB stick, and only read it when signing certificates.		The first means we've got to keep a copy of the private key file in some other, safe location, and we've got to secure the private key on the server where it sits - both the machine and the file. It might even be wise to remove the private key, and keep it on a USB stick, and only read it when signing certificates.
	The second thing means we've got to generate keys for SSL and TLS connections, just as we need them. This is covered in our [[Creating digital certificates with our root certificate \| creating digital certificates]] section.		The second thing means we've got to generate keys for SSL and TLS connections, just as we need them. This is covered in our [[Creating digital certificates with our root certificate \| creating digital certificates]] section.
			The last point means we need to send out our public CA certificate. In some cases, you can provide others with your ''.pem'' file, but in other cases you're better off providing a simpler ''.crt'' file. The difference is explained nicely at the [http://info.ssl.com/article.aspx?id=12149 ssl.com site]
			To create a public CA certificate in .crt format you can issue the following command:
			openssl x509 -outform der -in cacert.pem -out cacert.crt
			By the way, it's usually better to distribute the public certificate with a more recognizable file name, such as ''saruman.biz.crt''

Saruman!: /* Creating the CA root certificate key pair */ expanded with checks

2016-10-29T19:40:20Z

Creating the CA root certificate key pair: expanded with checks

← Older revision		Revision as of 19:40, 29 October 2016
Line 103:		Line 103:
	The next step in our CA creation process thus ''again'' asks for the passphrase. Since this is the second step in a two-step process, we again put in the passphrase we've already provided. However, now the shellscript uses this to unlock the private key we've (already) created, and then use it to sign the public key we're now creating. However, the passphrase is ''all'' that it asks. It now generates a signing request (''/etc/openssl/ca/careq.pem''), then uses the private key to sign it, and then generate the public key, to be found in ''/etc/openssl/ca/cacert.pem''. You can remove ''careq.pem'' after you've inspected the ''cacert.pem''.		The next step in our CA creation process thus ''again'' asks for the passphrase. Since this is the second step in a two-step process, we again put in the passphrase we've already provided. However, now the shellscript uses this to unlock the private key we've (already) created, and then use it to sign the public key we're now creating. However, the passphrase is ''all'' that it asks. It now generates a signing request (''/etc/openssl/ca/careq.pem''), then uses the private key to sign it, and then generate the public key, to be found in ''/etc/openssl/ca/cacert.pem''. You can remove ''careq.pem'' after you've inspected the ''cacert.pem''.

	So now we've got two root certificates, namely '''private''' key ''/etc/openssl/ca/private/cakey.pem'' and '''public''' key ''/etc/openssl/ca/cacert.pem''. NEVER send your ~~public~~ key out to ANYONE! Protect that key, and its passphrase, with your life. If you lose the file, lose the passphrase, or the key gets compromised (lost to an unknown party) then you've got to replace your root certificates AND you'll have to re-issue ALL certificates that you've ever signed (we're not going into certificate revocation here).		So now we've got two root certificates, namely
			* '''private''' key ''/etc/openssl/ca/private/cakey.pem'', and
			* '''public''' key ''/etc/openssl/ca/cacert.pem''.
			NEVER send your private key out to ANYONE! Protect that key, and its passphrase, with your life. If you lose the file, lose the passphrase, or the key gets compromised (lost to an unknown party) then you've got to replace your root certificates AND you'll have to re-issue ALL certificates that you've ever signed (we're not going into certificate revocation here).

	You can inspect your certificates (when you're in directory ''/etc/openssl/ca'') with commands like this:		You can inspect your certificates (when you're in directory ''/etc/openssl/ca'') with commands like this:
Line 109:		Line 112:
	openssl x509 -in cacert.pem -noout -dates		openssl x509 -in cacert.pem -noout -dates
	openssl x509 -in cacert.pem -noout -purpose		openssl x509 -in cacert.pem -noout -purpose
	Note from the last command that this certificate is obviously a root certificate: it can ~~sign~~ everything but the kitchen sink.		Note from the last command above, that this certificate is obviously a root certificate: it can verify the signature of everything but the kitchen sink.

			In the same manner you can inspect your private key:
			openssl rsa -in private/cakey.pem -noout -text

			Note that this can be used to check if the private key and certificate belong together: the `modulus' and the `public exponent' portions in the private
			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 -in cacert.pem -noout -modulus \| openssl md5
			openssl rsa -in private/cakey.pem -noout -modulus \| openssl md5
			And then compare these really shorter numbers. Both commands will output something like:
			(stdin)= 96a281eca852b794a907186a9703ddf4
			With overwhelming probability they will differ if the keys are different.

	===We've got the CA certificate, now what?===		===We've got the CA certificate, now what?===

Saruman!: reordered

2016-02-23T09:23:28Z

reordered

@@ Line 51: / Line 51: @@
 |-
 |}
 === Editing the ''openssl.cnf'' configuration file===
@@ Line 87: / Line 73: @@
   countryName_default         = NL
 Especially the last section is, again, a pretty arbitrary choice. You could choose not to provide customized default answers (in which case you're stuck with Internet Widgets Pty from Some-State, AU as the default answers). There are more default values in that section of the ''openssl.cnf'' configuration file; go in there and decide what you want.
 ==the Certificate Authority root certificate==

Saruman!: /* Editing the CA.sh script */

2016-02-23T09:19:31Z

Editing the CA.sh script

← Older revision		Revision as of 09:19, 23 February 2016
Line 55:		Line 55:
	Actually, you don't need to use the ''CA.sh'' shell script. There's also a ''CA.pl'' perl script. However, if you're more into shell scripting than perl programming, go for the shell script.		Actually, you don't need to use the ''CA.sh'' shell script. There's also a ''CA.pl'' perl script. However, if you're more into shell scripting than perl programming, go for the shell script.

	~~Now~~ edit ''/usr/lib/ssl/misc/CA.sh''; find the two lines near the top that define the variables ''DAYS'' and ''CADAYS'', and set these to what we want them to be~~. A little further down, we find the default location ''CATOP=./demoCA''. Change this (relative) path to the (absolute) path we've decided upon~~. Then, a lot further down, we find the line that's responsible for creating the CA root certificate itself, it's the line that goes ''$REQ -new -keyout ${CATOP}/private/$CAKEY -out ${CATOP}/$CAREQ'' (well actually it's split out over two lines). Here, right after ''-new'' we add ''-newkey rsa:~~2048~~''.		Unfortunately, not everything we want to change is actually set from the ''openssl.conf'' file. So we edit ''/usr/lib/ssl/misc/CA.sh''; find the two lines near the top that define the variables ''DAYS'' and ''CADAYS'', and set these to what we want them to be. Then, a lot further down, we find the line that's responsible for creating the CA root certificate itself, it's the line that goes ''$REQ -new -keyout ${CATOP}/private/$CAKEY -out ${CATOP}/$CAREQ'' (well actually it's split out over two lines). Here, right after ''-new'' we add ''-newkey rsa:4096''.

	With all these changes, the three relevant sections in ''CA.sh'' will be changed to something like this:		With all these changes, the three relevant sections in ''CA.sh'' will be changed to something like this:
	~~<source lang="bash">~~
	DAYS="-days 370" # 1 year		DAYS="-days 370" # 1 year
	CADAYS="-days 5479" # 15 years		CADAYS="-days 5479" # 15 years
	...		...
	~~CATOP=/etc/ssl/ca~~		echo "Making CA certificate ..."
	~~...~~		$REQ -new -newkey rsa:4096 -keyout ${CATOP}/private/$CAKEY \
	echo "Making CA certificate ..."
	$REQ -new -newkey rsa:~~2048~~ -keyout ${CATOP}/private/$CAKEY \
	-out ${CATOP}/$CAREQ		-out ${CATOP}/$CAREQ
	~~</source>~~

	=== Editing the ''openssl.cnf'' configuration file===		=== Editing the ''openssl.cnf'' configuration file===

Saruman!: /* Deciding on CA parameters */

2016-02-23T09:02:29Z

Deciding on CA parameters

← Older revision		Revision as of 09:02, 23 February 2016
Line 12:		Line 12:
	'''How strong''' do we want our root certificate? 1024 bits is the default, but the stronger, the better. We suggest 4096 bits - not because 2048 isn't sufficient (even 1024 is still very very good, even in the year 2016), but because it's not necessary to keep a CA's key length very low, and 4096 can be expected to remain pretty secure until after 2030 (see [http://danielpocock.com/rsa-key-sizes-2048-or-4096-bits here]).		'''How strong''' do we want our root certificate? 1024 bits is the default, but the stronger, the better. We suggest 4096 bits - not because 2048 isn't sufficient (even 1024 is still very very good, even in the year 2016), but because it's not necessary to keep a CA's key length very low, and 4096 can be expected to remain pretty secure until after 2030 (see [http://danielpocock.com/rsa-key-sizes-2048-or-4096-bits here]).

	How long should our '''CA root certificate remain valid'''? The longer, the more convenient - but maybe some day in the future, you feel you don't want certificates ~~from~~ ten years ~~earlies~~ to ~~wander~~ around, expired but otherwise valid. Expiry of the root certificate that goes along with that certificate might help you. So what's an appropriate time for your root CA? That depends. For our home CA, we use 15 years. For a business, the cost of providing new root certificates to all computers, employees, and maybe customers, can be so high that you'd rather have 25 years - or maybe security is paramount, and 5 years is long enough for you. We can't say - but our home CA's use 15 years, because we feel that that's a nice intermediate value. 15 years, including about 4 leap days, comes to 5479 days.		How long should our '''CA root certificate remain valid'''? The longer, the more convenient - but maybe some day in the future, you feel you don't want certificates issued ten years ago to just lie around, expired but otherwise valid. Expiry of the root certificate that goes along with that certificate might help you. So what's an appropriate time for your root CA? That depends. For our home CA, we use 15 years. For a business, the cost of providing new root certificates to all computers, employees, and maybe customers, can be so high that you'd rather have 25 years - or maybe security is paramount, and 5 years is long enough for you. We can't say - but our home CA's use 15 years, because we feel that that's a nice intermediate value. 15 years, including about 4 leap days, comes to 5479 days.

	'''Where do we want to store''' our CA root certificate? By default, the ''CA.sh'' script feels it must store all generated certificates in ''./demoCA''. That's not very handy for us. We rather have a central location like ''/etc/ssl/ca'' on our ~~central~~ server.		'''Where do we want to store''' our CA root certificate? By default, the ''CA.sh'' script feels it must store all generated certificates in ''./demoCA''. That's not very handy for us. We rather have a central location like ''/etc/ssl/ca'' on our home server. Yes, it's sound advice to keep the root certificate on an offline machine and all that, but this is for a self-signed certificate, and if this particular directory gets compromised, then so is the whole home server, and we've got greater issues than the loss of a self-signed private key.

	How long should '''any generated certificate be valid'''? The default value that the ''CA.sh'' script provides is one year. We find that enough - although we add 7 days to accommodate some overlap when having to regenerate the certificate upon nearing the expiry date (note: we really want to replace certificates ''prior'' to expiry :-)		How long should '''any generated certificate be valid'''? The default value that the ''CA.sh'' script provides is one year. We find that enough - although we add 7 days to accommodate some overlap when having to regenerate the certificate upon nearing the expiry date (note: we really want to replace certificates ''prior'' to expiry :-)
Line 20:		Line 20:
	'''What "company" data''' will we enter in the certificate? Several fields must be entered, some of which you could fill out at will. However, it's not exactly clear why you would want to confuse people trying to authenticate you, your webserver or some other connection by filling out, for example, the country with an incorrect or even non-existent code. On the other hand, you can keep your own privacy in mind, and not fill in your full name, but rather your website's name, at the "common name" section of your CA root certificate. Again, this depends on what you're going to use your CA for. We at [https://www.saruman.biz saruman.biz] decided to use the following values:		'''What "company" data''' will we enter in the certificate? Several fields must be entered, some of which you could fill out at will. However, it's not exactly clear why you would want to confuse people trying to authenticate you, your webserver or some other connection by filling out, for example, the country with an incorrect or even non-existent code. On the other hand, you can keep your own privacy in mind, and not fill in your full name, but rather your website's name, at the "common name" section of your CA root certificate. Again, this depends on what you're going to use your CA for. We at [https://www.saruman.biz saruman.biz] decided to use the following values:
	* Organization name: Saruman.biz. We're private persons, not companies, but we want to maintain a minimum of privacy, so we've put this fake entity name here.		* Organization name: Saruman.biz. We're private persons, not companies, but we want to maintain a minimum of privacy, so we've put this fake entity name here.
	* Province: Utrecht. Yep, that's a province in the Netherlands, and we live pretty close to it.
	* Country: NL (that's the Netherlands)		* Country: NL (that's the Netherlands)
			* Province: Utrecht. Yep, that's a province in the Netherlands, and I happen to live in it.
	Maybe you want to provide more default information to your CA setup; just look further down on how to.		Maybe you want to provide more default information to your CA setup; just look further down on how to.

Saruman!: /* Creating the Certificate Authority (CA) - preparations */

2016-02-22T12:11:30Z

Creating the Certificate Authority (CA) - preparations

← Older revision		Revision as of 12:11, 22 February 2016
Line 7:		Line 7:

	==Creating the Certificate Authority (CA) - preparations==		==Creating the Certificate Authority (CA) - preparations==
	To generate the root CA for our own little organization, we first need tools. These tools under Debian come with the OpenSSL software - which you'll usually find already installed. Now to generate the CA root certificate, we'll use a shell script from the OpenSSL package: ''/usr/lib/ssl/misc/CA.sh'', which together with the configuration file ''/etc/ssl/openssl.cnf'' can create our CA root certificate. To that end, we'll first need to decide on some parameters.		To generate the root CA for our own little organization, we first need tools. These tools under Debian come with the OpenSSL software - which you'll usually find already installed (if not, run ''apt-get install openssl''). Now to generate the CA root certificate, we'll use a shell script from the OpenSSL package: ''/usr/lib/ssl/misc/CA.sh'', which together with the configuration file ''/etc/ssl/openssl.cnf'' can create our CA root certificate. To that end, we'll first need to decide on some parameters.

	===Deciding on CA parameters===		===Deciding on CA parameters===
Line 16:		Line 16:
	'''Where do we want to store''' our CA root certificate? By default, the ''CA.sh'' script feels it must store all generated certificates in ''./demoCA''. That's not very handy for us. We rather have a central location like ''/etc/ssl/ca'' on our central server.		'''Where do we want to store''' our CA root certificate? By default, the ''CA.sh'' script feels it must store all generated certificates in ''./demoCA''. That's not very handy for us. We rather have a central location like ''/etc/ssl/ca'' on our central server.

	How long should '''any generated certificate be valid'''? The default value that the ''CA.sh'' script provides is one year. We find that enough - although we add 7 days to ~~accomodate~~ some overlap when having to regenerate the certificate upon nearing the expiry date (note: we really want to replace certificates ''prior'' to expiry :-)		How long should '''any generated certificate be valid'''? The default value that the ''CA.sh'' script provides is one year. We find that enough - although we add 7 days to accommodate some overlap when having to regenerate the certificate upon nearing the expiry date (note: we really want to replace certificates ''prior'' to expiry :-)

	'''What "company" data''' will we enter in the certificate? Several fields must be entered, some of which you could fill out at will. However, it's not exactly clear why you would want to confuse people trying to authenticate you, your webserver or some other connection by filling out, for example, the country with an incorrect or even non-existent code. On the other hand, you can keep your own privacy in mind, and not fill in your full name, but rather your website's name, at the "common name" section of your CA root certificate. Again, this depends on what you're going to use your CA for. We at [https://www.saruman.biz saruman.biz] decided to use the following values:		'''What "company" data''' will we enter in the certificate? Several fields must be entered, some of which you could fill out at will. However, it's not exactly clear why you would want to confuse people trying to authenticate you, your webserver or some other connection by filling out, for example, the country with an incorrect or even non-existent code. On the other hand, you can keep your own privacy in mind, and not fill in your full name, but rather your website's name, at the "common name" section of your CA root certificate. Again, this depends on what you're going to use your CA for. We at [https://www.saruman.biz saruman.biz] decided to use the following values: