Please Clarify.Intermediate certificate verification ?

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

Please Clarify.Intermediate certificate verification ?

Mr.Rout
Folks,

Can somebody clarify my doubts on below questions

1) what is intermediate certificate validation ?
2) Is it required to keep chained certificate or End user certificate at Server Side
3) How to generate intermediate certificate using Openssl command ?

Please clarify.

Thanks in advance.

Best Regards,
Mr. Rout
Reply | Threaded
Open this post in threaded view
|

RE: Please Clarify.Intermediate certificate verification ?

Edward Ned Harvey (openssl)
> From: [hidden email] [mailto:owner-openssl-
> [hidden email]] On Behalf Of Mr.Rout
>
> 1) what is intermediate certificate validation ?

When you generate a CSR, the CA can sign it directly, or they can sign it
via an intermediate.  I'm not quite sure what's the point of the
intermediate, but the root CA signs the intermediate, and the intermediate
signs the CSR.  I think this allows for varying levels of trust - If you're
using a cheap or free root CA, you probably just have a really low level of
verification.  You were able to read an email they sent to somebody presumed
to be authoritative for that domain or whatnot.


> 2) Is it required to keep chained certificate or End user certificate at
> Server Side

Generally, if your server cert is signed via intermediate, your server will
need the server cert + the root cert + the intermediate.


> 3) How to generate intermediate certificate using Openssl command ?

If you are self-signing your certs, I think you probably want to skip the
intermediate, and just sign directly with your root.

______________________________________________________________________
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: Please Clarify.Intermediate certificate verification ?

Dave Thompson-5
> From: [hidden email] On Behalf Of Edward Ned Harvey
> Sent: Tuesday, 06 March, 2012 13:18

> > From: [hidden email] [mailto:owner-openssl-
> > [hidden email]] On Behalf Of Mr.Rout
> >
> > 1) what is intermediate certificate validation ?
>
> When you generate a CSR, the CA can sign it directly, or they
> can sign it
> via an intermediate.  I'm not quite sure what's the point of the

Nits: The CSR isn't signed by the CA; the cert is. The cert is
based on the CSR but is NOT the same. The CA can sign your cert
directly *by their root*, or by an intermediate under their root.

> intermediate, but the root CA signs the intermediate, and the
> intermediate
> signs the CSR.  I think this allows for varying levels of
> trust - If you're
> using a cheap or free root CA, you probably just have a
> really low level of
> verification.  You were able to read an email they sent to
> somebody presumed
> to be authoritative for that domain or whatnot.
>
It does allow more easily specifying different policies,
and changing them, although most users don't pay attention
except EV. It can also reduce the size of CRLs, and perhaps
distribute CRLDP or OCSP load if that becomes an issue.

It also allows keeping the root key better protected offline.
An intermediate CA cert can be revoked and replaced easily,
and can be reissued at frequent intervals if desired as long
as the child certs under it are equally short-lived.

Revoking, replacing, or reissuing a root requires updating all
reliers, which for the public Web means all browsers. E.g.
when the Diginotar breach happened, MS had to push an update
to all PCs, and Firefox had to release a whole new version.

It also allows new or 'spinoff' CAs to inherit trust from an
already distributed root until they establish their own root,
and can allow a subsidiary CA to inherit trust on an ongoing
basis (although that trust can also be abused).

These reasons can combine to produce 2 levels of intermediate
cert in a chain, and possibly even more (but rarely).

>
> > 2) Is it required to keep chained certificate or End user
> certificate at
> > Server Side
>
> Generally, if your server cert is signed via intermediate,
> your server will
> need the server cert + the root cert + the intermediate.
>
An SSL server (or client using client auth) should never need
to send its root, because the client (or server) must ignore
any root received and trust only those configured locally.
OTOH it may be more convenient to configure it, especially if
using the same key/truststore in both directions, and it does
no harm other than wasting a little bandwidth, which for most
devices and users today is unnoticeable.

You do need to send any and all intermediate(s) -- unless you
know the recipient already has them, which you usually don't.

>
> > 3) How to generate intermediate certificate using Openssl command ?
>
> If you are self-signing your certs, I think you probably want
> to skip the
> intermediate, and just sign directly with your root.
>
Although if you *want* to do your own intermediate CAs&certs
for whatever reason, OpenSSL commandline can do that with
appropriate configuration and/or options. (And of course
the library can be used to construct whatever you code for.)


______________________________________________________________________
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: Please Clarify.Intermediate certificate verification ?

Jakob Bohm-7
On 3/7/2012 2:06 AM, Dave Thompson wrote:

>> From: [hidden email] On Behalf Of Edward Ned Harvey
>> Sent: Tuesday, 06 March, 2012 13:18
>>> From: [hidden email] [mailto:owner-openssl-
>>> [hidden email]] On Behalf Of Mr.Rout
>>>
>>> 1) what is intermediate certificate validation ?
>> When you generate a CSR, the CA can sign it directly, or they
>> can sign it
>> via an intermediate.  I'm not quite sure what's the point of the
> Nits: The CSR isn't signed by the CA; the cert is. The cert is
> based on the CSR but is NOT the same. The CA can sign your cert
> directly *by their root*, or by an intermediate under their root.
>
>> intermediate, but the root CA signs the intermediate, and the
>> intermediate
>> signs the CSR.  I think this allows for varying levels of
>> trust - If you're
>> using a cheap or free root CA, you probably just have a
>> really low level of
>> verification.  You were able to read an email they sent to
>> somebody presumed
>> to be authoritative for that domain or whatnot.
>>
> It does allow more easily specifying different policies,
> and changing them, although most users don't pay attention
> except EV. It can also reduce the size of CRLs, and perhaps
> distribute CRLDP or OCSP load if that becomes an issue.
>
> It also allows keeping the root key better protected offline.
> An intermediate CA cert can be revoked and replaced easily,
> and can be reissued at frequent intervals if desired as long
> as the child certs under it are equally short-lived.
>
> Revoking, replacing, or reissuing a root requires updating all
> reliers, which for the public Web means all browsers. E.g.
> when the Diginotar breach happened, MS had to push an update
> to all PCs, and Firefox had to release a whole new version.
>
> It also allows new or 'spinoff' CAs to inherit trust from an
> already distributed root until they establish their own root,
> and can allow a subsidiary CA to inherit trust on an ongoing
> basis (although that trust can also be abused).
>
> These reasons can combine to produce 2 levels of intermediate
> cert in a chain, and possibly even more (but rarely).
Another reason is if the intermediary cert is delegated
to some other trusted entity.

For instance a CA who bases its verification on people
showing up at a lawyers office to prove their identity
might create an intermediary cert for each so trusted
lawyers office, thus making it clear to everybody who
really issued the cert and allowing them to revoke all
certs issued by some crooked lawyer in one single
operation.  Some of the compromised Diginotar
certificates were such intermediary CAs issued by other
non-Diginotar root CAs.

In the original X.509 scheme, the idea was that the UN
or the CCITT/ITU-T would be the root CA, issuing an
intermediary CA to each legitimate Government, who
would then issue one for each province/state, who
would then issue one for each licensed phone company,
who would then issue certificates to all subscribers
specifying the same information also printed in the
phone book.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]