OpenSSL PKI Tutorial updated

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSSL PKI Tutorial updated

Stefan H. Holek
Hi All,

I have updated the OpenSSL PKI Tutorial at Read the Docs. The tutorial provides three complete PKI examples you can play through and the prettiest configuration files this side of Neptune. Check it out!

https://pki-tutorial.readthedocs.org/

Cheers,
Stefan

--
Stefan H. Holek
[hidden email]

______________________________________________________________________
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: OpenSSL PKI Tutorial updated

Zack Williams
On Fri, Mar 21, 2014 at 12:25 AM, Stefan H. Holek <[hidden email]> wrote:
> I have updated the OpenSSL PKI Tutorial at Read the Docs. The tutorial provides three complete PKI examples you can play through and the prettiest configuration files this side of Neptune. Check it out!
>
> https://pki-tutorial.readthedocs.org/

This is really awesome.   I've been trying to make sense of the config
files for cert generation and align to best practices (when I can find
them), and having good documentation is great.

A few questions:

1. Is there a reason you're not using SHA-256 hash by default - it
appears that SHA1 is being recommended against currently:
http://www.digicert.com/sha-2-ssl-certificates.htm

2. I couldn't figure out what the [additional_oids] section of the
Expert example's root-ca.conf file is for - either through research or
going through the commit history.  Could you elaborate on what that
accomplishes?

https://pki-tutorial.readthedocs.org/en/latest/expert/root-ca.conf.html

3. Is there a reason to not set a pathLen in the basicConstraints
section of the Root CA's (to 1, to allow a maximum of one layer of
CA's below the Root), but to do so on the Intermediate CA's?

Thanks,
Zack
______________________________________________________________________
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: [openssl-users] Re: OpenSSL PKI Tutorial updated

Erwann ABALEA
Le 25/03/2014 17:44, Zack Williams a écrit :

> On Fri, Mar 21, 2014 at 12:25 AM, Stefan H. Holek <[hidden email]> wrote:
>> I have updated the OpenSSL PKI Tutorial at Read the Docs. The tutorial provides three complete PKI examples you can play through and the prettiest configuration files this side of Neptune. Check it out!
>>
>> https://pki-tutorial.readthedocs.org/
> This is really awesome.   I've been trying to make sense of the config
> files for cert generation and align to best practices (when I can find
> them), and having good documentation is great.
>
> A few questions:
>
> 1. Is there a reason you're not using SHA-256 hash by default - it
> appears that SHA1 is being recommended against currently:
> http://www.digicert.com/sha-2-ssl-certificates.htm

Good point.

> 2. I couldn't figure out what the [additional_oids] section of the
> Expert example's root-ca.conf file is for - either through research or
> going through the commit history.  Could you elaborate on what that
> accomplishes?
>
> https://pki-tutorial.readthedocs.org/en/latest/expert/root-ca.conf.html

The OIDs are used in the CertificatePolicies extension of a subordinate
CA of this root CA.
For a policyId to be acceptable for an end-user certificate, this same
policyId (or the special value anyPolicy) MUST be present in all CAs
between this end-user cert and the root CA. The root CA is special in
that it doesn't need to contain any CertificatePolicies extension.

> 3. Is there a reason to not set a pathLen in the basicConstraints
> section of the Root CA's (to 1, to allow a maximum of one layer of
> CA's below the Root), but to do so on the Intermediate CA's?

Because it's not used by the standardized validation algorithm (RFC5280
section 6, X.509 section 10).
______________________________________________________________________
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: OpenSSL PKI Tutorial updated

Vivek Ganta
In reply to this post by Zack Williams
Hi Team.,

I need some documentation how to upgrade the existing openssl and also how to downgrade the openssl.

My requirement is to upgrade the existing openssl 0.9.8e to openssl 1.0.1e 
                                    downgrade  openssl 1.0.1e to 0.9.8e


Also open ssl 1.0.1 will work on OEL 5.9 and 6.x?

Please let me know.

Thanks,
Vivek






On Tue, Mar 25, 2014 at 9:44 AM, Zack Williams <[hidden email]> wrote:
On Fri, Mar 21, 2014 at 12:25 AM, Stefan H. Holek <[hidden email]> wrote:
> I have updated the OpenSSL PKI Tutorial at Read the Docs. The tutorial provides three complete PKI examples you can play through and the prettiest configuration files this side of Neptune. Check it out!
>
> https://pki-tutorial.readthedocs.org/

This is really awesome.   I've been trying to make sense of the config
files for cert generation and align to best practices (when I can find
them), and having good documentation is great.

A few questions:

1. Is there a reason you're not using SHA-256 hash by default - it
appears that SHA1 is being recommended against currently:
http://www.digicert.com/sha-2-ssl-certificates.htm

2. I couldn't figure out what the [additional_oids] section of the
Expert example's root-ca.conf file is for - either through research or
going through the commit history.  Could you elaborate on what that
accomplishes?

https://pki-tutorial.readthedocs.org/en/latest/expert/root-ca.conf.html

3. Is there a reason to not set a pathLen in the basicConstraints
section of the Root CA's (to 1, to allow a maximum of one layer of
CA's below the Root), but to do so on the Intermediate CA's?

Thanks,
Zack
______________________________________________________________________
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: [openssl-users] Re: OpenSSL PKI Tutorial updated

Zack Williams
In reply to this post by Erwann ABALEA
On Tue, Mar 25, 2014 at 10:54 AM, Erwann Abalea
<[hidden email]> wrote:

>
>> 2. I couldn't figure out what the [additional_oids] section of the
>> Expert example's root-ca.conf file is for - either through research or
>> going through the commit history.  Could you elaborate on what that
>> accomplishes?
>>
>> https://pki-tutorial.readthedocs.org/en/latest/expert/root-ca.conf.html
>
> The OIDs are used in the CertificatePolicies extension of a subordinate CA
> of this root CA.
> For a policyId to be acceptable for an end-user certificate, this same
> policyId (or the special value anyPolicy) MUST be present in all CAs between
> this end-user cert and the root CA. The root CA is special in that it
> doesn't need to contain any CertificatePolicies extension.

So these are used to group or link the certificate chain together?

Is there guidance for generating and naming this OID? Given an OID in this form:

1.3.6.1.4.1.X.Y.Z

I'm assuming that you would register the top level number (X) with the
IANA (or other appropriate issuing body), but is there guidance to
setting Y and Z, which are 7 and 8 or 9 respectively in the Expert
example?

>> 3. Is there a reason to not set a pathLen in the basicConstraints
>> section of the Root CA's (to 1, to allow a maximum of one layer of
>> CA's below the Root), but to do so on the Intermediate CA's?
>
> Because it's not used by the standardized validation algorithm (RFC5280
> section 6, X.509 section 10).

I looked through RFC5280 section 6.1.4 (m), and it appears that
setting the pathLen would apply to the Root CA, and would cause
section (l) to fail on CA's created beyond the depth specified.  Am I
interpreting the RFC incorrectly?

Thanks,
Zack
______________________________________________________________________
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: [openssl-users] Re: OpenSSL PKI Tutorial updated

Erwann ABALEA
Le 25/03/2014 23:08, Zack Williams a écrit :

> On Tue, Mar 25, 2014 at 10:54 AM, Erwann Abalea
> <[hidden email]> wrote:
>>> 2. I couldn't figure out what the [additional_oids] section of the
>>> Expert example's root-ca.conf file is for - either through research or
>>> going through the commit history.  Could you elaborate on what that
>>> accomplishes?
>>>
>>> https://pki-tutorial.readthedocs.org/en/latest/expert/root-ca.conf.html
>> The OIDs are used in the CertificatePolicies extension of a subordinate CA
>> of this root CA.
>> For a policyId to be acceptable for an end-user certificate, this same
>> policyId (or the special value anyPolicy) MUST be present in all CAs between
>> this end-user cert and the root CA. The root CA is special in that it
>> doesn't need to contain any CertificatePolicies extension.
> So these are used to group or link the certificate chain together?

No, it's about authorized uses of certificates.

Certificate policy is defined by the X.509 recommendation as:
"A named set of rules that indicates the applicability of a certificate
to a particular community and/or class of application with common
security requirements. For example, a particular certificate policy
might indicate applicability of a type of certificate to the
authentication of electronic data interchange transactions for the
trading of goods within a given price range."

What identifies a specific CP is a policyId, and it's represented by an
OID. Having a policyId declared or not in a CA allows for its issuing CA
to allow or deny the right of this subCA to deliver certificates that
can be used in accordance to this CP.


> Is there guidance for generating and naming this OID? Given an OID in this form:
>
> 1.3.6.1.4.1.X.Y.Z
>
> I'm assuming that you would register the top level number (X) with the
> IANA (or other appropriate issuing body), but is there guidance to
> setting Y and Z, which are 7 and 8 or 9 respectively in the Expert
> example?

No guidance necessary, everyone is free to shape its OID space as wanted.

>>> 3. Is there a reason to not set a pathLen in the basicConstraints
>>> section of the Root CA's (to 1, to allow a maximum of one layer of
>>> CA's below the Root), but to do so on the Intermediate CA's?
>> Because it's not used by the standardized validation algorithm (RFC5280
>> section 6, X.509 section 10).
> I looked through RFC5280 section 6.1.4 (m), and it appears that
> setting the pathLen would apply to the Root CA, and would cause
> section (l) to fail on CA's created beyond the depth specified.  Am I
> interpreting the RFC incorrectly?

You overlooked this, in 6.1:

[...]
    To meet this goal, the path validation process verifies, among other
    things, that a prospective certification path (a sequence of n
    certificates) satisfies the following conditions:

       (a)  for all x in {1, ..., n-1}, the subject of certificate x is
            the issuer of certificate x+1;

       (b)  certificate 1 is issued by the trust anchor;

       (c)  certificate n is the certificate to be validated (i.e., the
            target certificate); and

       (d)  for all x in {1, ..., n}, the certificate was valid at the
            time in question.
[...]

Point (b) is important.

Now look at 6.1.2 (Initialization), point (k):
-----
       (k)  max_path_length:  this integer is initialized to n, is
            decremented for each non-self-issued certificate in the path,
            and may be reduced to the value in the path length constraint
            field within the basic constraints extension of a CA
            certificate.
-----
and you'll understand that any BasicConstraints:pathLenConstraint set in
the Trust Anchor isn't used at all.

______________________________________________________________________
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: OpenSSL PKI Tutorial updated

Stefan H. Holek
In reply to this post by Zack Williams
On 25.03.2014, at 17:44, Zack Williams wrote:

> 1. Is there a reason you're not using SHA-256 hash by default - it
> appears that SHA1 is being recommended against currently:
> http://www.digicert.com/sha-2-ssl-certificates.htm

No reason. Just for maximum compatibility. Every software can do SHA1. But this comes up a lot and I might switch to sha256 the next time around.

> 2. I couldn't figure out what the [additional_oids] section of the
> Expert example's root-ca.conf file is for - either through research or
> going through the commit history.  Could you elaborate on what that
> accomplishes?

These define symbolic names for policy OIDs used in the certificatePolicies extension. You could well use the raw numbers without mapping them to names. Also note that policies are entirely optional and you are free to ignore them if you don't have a use case.

> 3. Is there a reason to not set a pathLen in the basicConstraints
> section of the Root CA's (to 1, to allow a maximum of one layer of
> CA's below the Root), but to do so on the Intermediate CA's?

Pathlen is not used on root CA certs. A lot of things are not used on root CA certs. They only serve to publish a key and ID. I don't use pathlen on intermediate CAs either, just signing CAs.

Thank you for your feedback,
Stefan

--
Stefan H. Holek
[hidden email]

______________________________________________________________________
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: OpenSSL PKI Tutorial updated

Jeffrey Walton-3
On Thu, Mar 27, 2014 at 5:47 AM, Stefan H. Holek <[hidden email]> wrote:
> On 25.03.2014, at 17:44, Zack Williams wrote:
>
>> ...
>> 3. Is there a reason to not set a pathLen in the basicConstraints
>> section of the Root CA's (to 1, to allow a maximum of one layer of
>> CA's below the Root), but to do so on the Intermediate CA's?
>
> Pathlen is not used on root CA certs. ...
RFC 5280 might disagree. For example, section 6.1.2 (k):

      (k)  max_path_length:  this integer is initialized to n, is
           decremented for each non-self-issued certificate in the path,
           and may be reduced to the value in the path length constraint
           field within the basic constraints extension of a CA
           certificate.
______________________________________________________________________
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: [openssl-users] Re: OpenSSL PKI Tutorial updated

Erwann ABALEA
Le 27/03/2014 11:14, Jeffrey Walton a écrit :

> On Thu, Mar 27, 2014 at 5:47 AM, Stefan H. Holek <[hidden email]> wrote:
>> On 25.03.2014, at 17:44, Zack Williams wrote:
>>
>>> ...
>>> 3. Is there a reason to not set a pathLen in the basicConstraints
>>> section of the Root CA's (to 1, to allow a maximum of one layer of
>>> CA's below the Root), but to do so on the Intermediate CA's?
>> Pathlen is not used on root CA certs. ...
> RFC 5280 might disagree. For example, section 6.1.2 (k):
>
>        (k)  max_path_length:  this integer is initialized to n, is
>             decremented for each non-self-issued certificate in the path,
>             and may be reduced to the value in the path length constraint
>             field within the basic constraints extension of a CA
>             certificate.

No disagreement here.
Initial value of the max_path_len is set to the length of certificate
chain, and it's not taken from the BasicConstraints extension of the
trust anchor. The rest of the phrase (after the first comma) explains
how it will decrease, but it's detailed later in the algo.
______________________________________________________________________
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: OpenSSL PKI Tutorial updated

Walter H.
In reply to this post by Stefan H. Holek
Hello,

On Thu, March 27, 2014 10:47, Stefan H. Holek wrote:

>> 3. Is there a reason to not set a pathLen in the basicConstraints
>> section of the Root CA's (to 1, to allow a maximum of one layer of
>> CA's below the Root), but to do so on the Intermediate CA's?
>
> Pathlen is not used on root CA certs. A lot of things are not used on root
> CA certs. They only serve to publish a key and ID. I don't use pathlen on
> intermediate CAs either, just signing CAs.

Does this mean, you use certificates with a complete chain of at least 4
certificates?

- root ca cert. no pathlen
- intermediate ca cert. also no pathlen
- signing ca cert. with pathlen
- end cert

what is here said about the key length?

my CA uses a root with 4096 bits RSA key; does it make a sense, that
an intermediate or the signing ca has a stronger key than the root CA?

Greetings,
Walter

______________________________________________________________________
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: OpenSSL PKI Tutorial updated

Stefan H. Holek
On 27.03.2014, at 13:32, Walter H. wrote:

> Does this mean, you use certificates with a complete chain of at least 4
> certificates?
>
> - root ca cert. no pathlen
> - intermediate ca cert. also no pathlen
> - signing ca cert. with pathlen
> - end cert

Yes, the expert example does that.

> what is here said about the key length?
>
> my CA uses a root with 4096 bits RSA key; does it make a sense, that
> an intermediate or the signing ca has a stronger key than the root CA?

I don't think so.

Stefan

--
Stefan H. Holek
[hidden email]

______________________________________________________________________
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: OpenSSL PKI Tutorial updated

Zack Williams
In reply to this post by Stefan H. Holek
On Thu, Mar 27, 2014 at 2:47 AM, Stefan H. Holek <[hidden email]> wrote:
> No reason. Just for maximum compatibility. Every software can do SHA1. But this comes up a lot and I might switch to sha256 the next time around.

It appears that even what most "legacy" web browsers and servers
support sha256, given these lists:

http://www.tbs-certificates.co.uk/FAQ/en/476.html
http://www.tbs-certificates.co.uk/FAQ/en/477.html

Are there other lists of other products that are modern (or still in
active use), but lack sha256 compatibility?

>> 2. I couldn't figure out what the [additional_oids] section of the
>> Expert example's root-ca.conf file is for - either through research or
>> going through the commit history.  Could you elaborate on what that
>> accomplishes?
>
> These define symbolic names for policy OIDs used in the certificatePolicies extension. You could well use the raw numbers without mapping them to names. Also note that policies are entirely optional and you are free to ignore them if you don't have a use case.

I assume that verifying that only correct/allowed OIDs are used in a
cert chain happens whether or not they get used by the rest of the
software, correct?  Or is this configurable?

> Thank you for your feedback,

Thank you for working on this!

- Zack
______________________________________________________________________
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: OpenSSL PKI Tutorial updated

Michael Wojcik
> From: [hidden email] [mailto:owner-openssl-
> [hidden email]] On Behalf Of Zack Williams
> Sent: Thursday, 27 March, 2014 20:26
>
> On Thu, Mar 27, 2014 at 2:47 AM, Stefan H. Holek <[hidden email]> wrote:
> > No reason. Just for maximum compatibility. Every software can do SHA1. But
> this comes up a lot and I might switch to sha256 the next time around.
>
> It appears that even what most "legacy" web browsers and servers
> support sha256, given these lists:
>
> http://www.tbs-certificates.co.uk/FAQ/en/476.html
> http://www.tbs-certificates.co.uk/FAQ/en/477.html
>
> Are there other lists of other products that are modern (or still in
> active use), but lack sha256 compatibility?

I'm in the process right now of updating Visibroker, a widely-used commercial product, to support certificates with SHA-256 signatures. (I don't believe that's proprietary information, and anyone with a copy of Visibroker can easily discover it by trying to use such a certificate.) My guess is it's not the only one.

That said, I think it makes sense to use SHA-256 in the tutorial. Anyone using it who runs into software that can't handle such certificates will get a useful bit of education in certificate signature algorithms.

--
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com
:��I"Ϯ��r�m���� (���Z+�K�+����1���x ��h���[�z�(���Z+� ��f�y������f���h��)z{,���