Best practices guidance for using OpenSSL to make cetificate authorities

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Best practices guidance for using OpenSSL to make cetificate authorities

Ted Byers
I found a Linux FAQ dealing with this subject, but it is very dated
(11.5 years old) and I do not know how much has changed since it was
last updated.  While I am a programmer, I am looking only to use
openssl to make the certificates and keys I need, and not to create
new programs using openssl (unless in the course of my studyign the
use of openssl, I find I need to write some custom code).

Here is what I want to do.  I want to create a certificate authority
to make certificates for a couple of my web servers, for the purpose
of having support for HTTPS, and if possible sign selected documents
that are then served to the user's browser (just those I selected, not
all by any means); with the ability to let the user download the
certificate to let him trust the server afterwards.  I also want to
support creating client side certificates that support encrypting and
signing emails and form data on web pages (to support non-repudiation,
with the assurance that the signed document was not altered since it
was signed).  None of the certificates I need need support for code
signing.

Do I need both root and non root CAs, or will a root CA suffice by itself.

And where should the keys and certificates be placed on Ubuntu and
Suse (I have both), and should I do all this as a normal user or as
root (NB: I am still trying to learn anough about administering Linux
that I can at least deal with the things I need to do on my Linux
boxes, so it is OK to be a little pedantic)?

I am a bit concerned about usability on the server as the FAQ I have
been reading (actually one of the clearest I have seen even though it
is old), since it says I should not remove the pass phrase from the
certificate, but I would think that would make HTTPS unusable since it
would ask the user for a password each time he asks for a resource
from the server.  At the same time, can I force a requirement that the
client side certificates require a password that has a reasonable
strength?  If so, how?

And for all this, will one opeenssl.cnf suffice, or do I have to make several?

Finally, is there a good document or example that tells me not only
what cofiguration options are available to enter in openssl.cnf, but
what values will provide me with the best security for the longest
period consistent with what is supported in the most commonly used
browsers?  Something that says something like 'This is X, and it is
for Y, but do not touch it unless you know what you're doing', and yet
provides no guidance for further reading so the user can learn what he
needs to know about all of it, is not so useful for my purposes.

NB: This is primarily for my own education.

Thank you for your time.

Ted
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Best practices guidance for using OpenSSL to make cetificate authorities

Ryan Hurst-3
This might be useful http://unmitigatedrisk.com/?p=194

Ryan Hurst


Sent from my phone, please forgive the brevity.

> On Oct 12, 2013, at 12:53 AM, Ted Byers <[hidden email]> wrote:
>
> I found a Linux FAQ dealing with this subject, but it is very dated
> (11.5 years old) and I do not know how much has changed since it was
> last updated.  While I am a programmer, I am looking only to use
> openssl to make the certificates and keys I need, and not to create
> new programs using openssl (unless in the course of my studyign the
> use of openssl, I find I need to write some custom code).
>
> Here is what I want to do.  I want to create a certificate authority
> to make certificates for a couple of my web servers, for the purpose
> of having support for HTTPS, and if possible sign selected documents
> that are then served to the user's browser (just those I selected, not
> all by any means); with the ability to let the user download the
> certificate to let him trust the server afterwards.  I also want to
> support creating client side certificates that support encrypting and
> signing emails and form data on web pages (to support non-repudiation,
> with the assurance that the signed document was not altered since it
> was signed).  None of the certificates I need need support for code
> signing.
>
> Do I need both root and non root CAs, or will a root CA suffice by itself.
>
> And where should the keys and certificates be placed on Ubuntu and
> Suse (I have both), and should I do all this as a normal user or as
> root (NB: I am still trying to learn anough about administering Linux
> that I can at least deal with the things I need to do on my Linux
> boxes, so it is OK to be a little pedantic)?
>
> I am a bit concerned about usability on the server as the FAQ I have
> been reading (actually one of the clearest I have seen even though it
> is old), since it says I should not remove the pass phrase from the
> certificate, but I would think that would make HTTPS unusable since it
> would ask the user for a password each time he asks for a resource
> from the server.  At the same time, can I force a requirement that the
> client side certificates require a password that has a reasonable
> strength?  If so, how?
>
> And for all this, will one opeenssl.cnf suffice, or do I have to make several?
>
> Finally, is there a good document or example that tells me not only
> what cofiguration options are available to enter in openssl.cnf, but
> what values will provide me with the best security for the longest
> period consistent with what is supported in the most commonly used
> browsers?  Something that says something like 'This is X, and it is
> for Y, but do not touch it unless you know what you're doing', and yet
> provides no guidance for further reading so the user can learn what he
> needs to know about all of it, is not so useful for my purposes.
>
> NB: This is primarily for my own education.
>
> Thank you for your time.
>
> Ted
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]