Personal CA: are cert serial numbers critical?

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

Personal CA: are cert serial numbers critical?

Tom Browder
Many years ago I started a CA for one group I manage for a private website, and now I want to update members' client certs for the stricter requirements for browsers.

My original cert generation was entirely automated including the following:

+ CN for each is an e-mail address for the member

+ the passphrase for each member's cert is determined from a pre-generated list by me, it will not change

I plan to tidy my automation before the issue of new certs, but I wonder how critical it is to ensure unique certificate serial numbers given that the certs are only used for us.  I'm not even sure I'll ever revoke any cert (they were issued to expire sometime in 2030).

So, in summary, do I need to ensure cert serial numbers are unique for my CA?

With warmest regards,

-Tom

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Michael Ströder
Tom Browder wrote:
> I plan to tidy my automation before the issue of new certs, but I wonder
> how critical it is to ensure unique certificate serial numbers given that
> the certs are only used for us.  I'm not even sure I'll ever revoke any
> cert (they were issued to expire sometime in 2030).
>
> So, in summary, do I need to ensure cert serial numbers are unique for my
> CA?

Yes, serial numbers should be unique per issuer-DN because the 2-tuple
(issuer-DN, cert serial no.) is expected to be unique in several protocols.

Ciao, Michael.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

OpenSSL - User mailing list
In reply to this post by Tom Browder
➢ So, in summary, do I need to ensure cert serial numbers are unique for my CA?

Why would you not?  The specifications require it, but those specifications are for interoperability. If nobody is ever going to see your certs, then who cares what’s in them?  

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Verhelst Wouter (Consultant)
In reply to this post by Tom Browder
On 16-08-17 15:24, Tom Browder wrote:
[...]
> I plan to tidy my automation before the issue of new certs, but I wonder
> how critical it is to ensure unique certificate serial numbers given
> that the certs are only used for us.  I'm not even sure I'll ever revoke
> any cert (they were issued to expire sometime in 2030).

You should revoke certificates when their private keys are compromised;
e.g., when the machine on which they were stored is stolen, lost, or
broken into by a remote attacker based on password guessing, user error,
social engineering, or something of the sorts. You aren't sure that any
of that will happen now, but usually people who are compromised never
expected that. Don't assume that just because they are
password-protected that they are safe; passwords will delay the
attacker, but not stop them.

To accomodate for that, you should generate the CRLs for your
certificates now, even if they're empty, and make sure that the software
you've configured to use your private CA are set up check the CRLs. That
way, when you become aware of a compromised private key of one of the
certificates, you don't need to hurry to reconfigure all those services,
but can simply revoke the certificate and possibly force critical
applications to reread the CRL (e.g., by restarting the service),
thereby turning a possibly full-day panicked "help I was compromised"
into a five-minute "certificate revoked, done" session.

> So, in summary, do I need to ensure cert serial numbers are unique for
> my CA?

Since CRLs expect that your serial numbers are unique, yes, you do need
to ensure that.

--
Wouter Verhelst
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Tom Browder
In reply to this post by Michael Ströder
On Wed, Aug 16, 2017 at 08:32 Michael Ströder <[hidden email]> wrote:
Tom Browder wrote:
...
> So, in summary, do I need to ensure cert serial numbers are unique for my
> CA?

Yes, serial numbers should be unique per issuer-DN because the 2-tuple
(issuer-DN, cert serial no.) is expected to be unique in several protocols.

Okay, that's good enough reason for me,

Thanks, Michael.

Cheers!

-Tom

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Tom Browder
In reply to this post by OpenSSL - User mailing list
On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users <[hidden email]> wrote:
➢ So, in summary, do I need to ensure cert serial numbers are unique for my CA?

Why would you not?  The specifications require it, but those specifications are for interoperability. If nobody is ever going to see your certs, then who cares what’s in them?

Well, I do like to abide by specs, and they will be used in various browsers, so I think I will continue the unique serial numbering.

Thanks, Rich.

Best regards,

-Tom

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Jakob Bohm-7
On 16/08/2017 16:32, Tom Browder wrote:

> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     ➢ So, in summary, do I need to ensure cert serial numbers are
>     unique for my CA?
>
>     Why would you not?  The specifications require it, but those
>     specifications are for interoperability. If nobody is ever going
>     to see your certs, then who cares what’s in them?
>
>
> Well, I do like to abide by specs, and they will be used in various
> browsers, so I think I will continue the unique serial numbering.
>
> Thanks, Rich.

Modern browsers increasingly presume that such private CAs behave exactly
like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
the per-browser root CA inclusion programs (the administrative processes
that determine which CAs are listed in browsers by default).

Among the relevant requirements now needed:

- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as
standalone
  numbers and as DER-encoded numbers.  Note that this is not the default in
  the openssl ca program.

- Serial numbers contain cryptographically strong random bits, currently at
  least 64 random bits, though it is best if the entire serial number looks
  random from the outside.  This is not implemented by the openssl ca
program.

- Certificates are valid for at most 2 years (actually 825 days).

- SHA-1 (and other weak algorithms such as MD5) are no longer permitted and
  is already disappearing from Browser code.

- RSA shorter than 2048 bits (and other weak settings such as equally short
  DSA keys) are no longer permitted and is already disappearing from
Browser
  code.

- If the certificate is issued to an e-mail address, that e-mail address
must
  also be listed as an rfc822Name in a "Subject Alternative Name"
certificate
  extension.

- End user certificates must be issued from an Intermediary CA whose
  certificate is is in turn issued from a longer term root CA.

- If revocation is implemented (it should be, just in case someone gets
their
  computer or other key storage hacked/stolen), it needs to support
OCSP, but
  should ideally do so without having the actual CA keys online
(standard trick:
  Issue 3-month non-revocable OCSP-signing certificates and provide the
  corresponding private key to the server running the OCSP responder
program).
   I would recommend to also implement traditional CRLs, since for
smaller CAs
  it is a better solution for browsers and servers that support it.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Gregory Sloop
Re: [openssl-users] Personal CA: are cert serial numbers critical? Replying personally:

I'm a nobody, and you have no reason to know me - but wanted to thank you for the input you give here.

You're nearly always quite thoughtful, careful in what you say, respectful, and give such [IMO] good insightful feedback and information to people looking for help. I follow quite a number of lists, and IMO, it's a rare breed of individuals who do such a fine job.

Perhaps you care nothing for such accolades, and I'm truly a "nobody" in giving them - but still I wanted to recognize excellence when I see it.

So, Thanks!

-Greg

JB> On 16/08/2017 16:32, Tom Browder wrote:
>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users
>> <
[hidden email] <[hidden email]>> wrote:

>>     ➢ So, in summary, do I need to ensure cert serial numbers are
>>     unique for my CA?

>>     Why would you not?  The specifications require it, but those
>>     specifications are for interoperability. If nobody is ever going
>>     to see your certs, then who cares what’s in them?


>> Well, I do like to abide by specs, and they will be used in various
>> browsers, so I think I will continue the unique serial numbering.

>> Thanks, Rich.

JB> Modern browsers increasingly presume that such private CAs behave exactly
JB> like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
JB> the per-browser root CA inclusion programs (the administrative processes
JB> that determine which CAs are listed in browsers by default).

JB> Among the relevant requirements now needed:

JB> - Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as
JB> standalone
JB>   numbers and as DER-encoded numbers.  Note that this is not the default in
JB>   the openssl ca program.

JB> - Serial numbers contain cryptographically strong random bits, currently at
JB>   least 64 random bits, though it is best if the entire serial number looks
JB>   random from the outside.  This is not implemented by the openssl ca
JB> program.

JB> - Certificates are valid for at most 2 years (actually 825 days).

JB> - SHA-1 (and other weak algorithms such as MD5) are no longer permitted and
JB>   is already disappearing from Browser code.

JB> - RSA shorter than 2048 bits (and other weak settings such as equally short
JB>   DSA keys) are no longer permitted and is already disappearing from
JB> Browser
JB>   code.

JB> - If the certificate is issued to an e-mail address, that e-mail address
JB> must
JB>   also be listed as an rfc822Name in a "Subject Alternative Name"
JB> certificate
JB>   extension.

JB> - End user certificates must be issued from an Intermediary CA whose
JB>   certificate is is in turn issued from a longer term root CA.

JB> - If revocation is implemented (it should be, just in case someone gets
JB> their
JB>   computer or other key storage hacked/stolen), it needs to support
JB> OCSP, but
JB>   should ideally do so without having the actual CA keys online
JB> (standard trick:
JB>   Issue 3-month non-revocable OCSP-signing certificates and provide the
JB>   corresponding private key to the server running the OCSP responder
JB> program).
JB>    I would recommend to also implement traditional CRLs, since for
JB> smaller CAs
JB>   it is a better solution for browsers and servers that support it.


JB> Enjoy

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


--
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x82
EMail:
[hidden email]
http://www.sloop.net
---
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

OpenSSL - User mailing list
In reply to this post by Jakob Bohm-7
Bonjour,

> Le 16 août 2017 à 16:51, Jakob Bohm <[hidden email]> a écrit :
>
> On 16/08/2017 16:32, Tom Browder wrote:
>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>    ➢ So, in summary, do I need to ensure cert serial numbers are
>>    unique for my CA?
>>
>>    Why would you not?  The specifications require it, but those
>>    specifications are for interoperability. If nobody is ever going
>>    to see your certs, then who cares what’s in them?
>>
>>
>> Well, I do like to abide by specs, and they will be used in various browsers, so I think I will continue the unique serial numbering.
>>
>> Thanks, Rich.
>
> Modern browsers increasingly presume that such private CAs behave exactly
> like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
> the per-browser root CA inclusion programs (the administrative processes
> that determine which CAs are listed in browsers by default).
>
> Among the relevant requirements now needed:
>
> - Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as standalone
> numbers and as DER-encoded numbers.  Note that this is not the default in
> the openssl ca program.

There’s no such requirement. It MUST be at most 20 octets long.

> - Serial numbers contain cryptographically strong random bits, currently at
> least 64 random bits, though it is best if the entire serial number looks
> random from the outside.  This is not implemented by the openssl ca program.

It can be easily done by an external script. Generate a secret key for your CA for a 128bits block cipher, keep the monotonic counter, but instead of putting the value of the counter in the serial number, encrypt the counter with the key+cipher, and use the resulting cipher text as the serial number. Of course, increment the counter.

> - Certificates are valid for at most 2 years (actually 825 days).
>
> - SHA-1 (and other weak algorithms such as MD5) are no longer permitted and
> is already disappearing from Browser code.
>
> - RSA shorter than 2048 bits (and other weak settings such as equally short
> DSA keys) are no longer permitted and is already disappearing from Browser
> code.
>
> - If the certificate is issued to an e-mail address, that e-mail address must
> also be listed as an rfc822Name in a "Subject Alternative Name" certificate
> extension.
>
> - End user certificates must be issued from an Intermediary CA whose
> certificate is is in turn issued from a longer term root CA.

I doubt browsers impose this on purely private CAs.

> - If revocation is implemented (it should be, just in case someone gets their
> computer or other key storage hacked/stolen), it needs to support OCSP, but
> should ideally do so without having the actual CA keys online (standard trick:
> Issue 3-month non-revocable OCSP-signing certificates and provide the
> corresponding private key to the server running the OCSP responder program).
>  I would recommend to also implement traditional CRLs, since for smaller CAs
> it is a better solution for browsers and servers that support it.

Another requirement is that a TLS server certificate shall have its identity (FQDN) in the SAN extension. Use of the commonName attribute has been deprecated long ago.

Cordialement,
Erwann Abalea

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Robert Moskowitz
In reply to this post by Jakob Bohm-7


On 08/16/2017 10:51 AM, Jakob Bohm wrote:

> On 16/08/2017 16:32, Tom Browder wrote:
>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     ➢ So, in summary, do I need to ensure cert serial numbers are
>>     unique for my CA?
>>
>>     Why would you not?  The specifications require it, but those
>>     specifications are for interoperability. If nobody is ever going
>>     to see your certs, then who cares what’s in them?
>>
>>
>> Well, I do like to abide by specs, and they will be used in various
>> browsers, so I think I will continue the unique serial numbering.
>>
>> Thanks, Rich.
>
> Modern browsers increasingly presume that such private CAs behave exactly
> like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
> the per-browser root CA inclusion programs (the administrative processes
> that determine which CAs are listed in browsers by default).
>
> Among the relevant requirements now needed:
>
> - Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as
> standalone
>  numbers and as DER-encoded numbers.  Note that this is not the
> default in
>  the openssl ca program.
>
> - Serial numbers contain cryptographically strong random bits,
> currently at
>  least 64 random bits, though it is best if the entire serial number
> looks
>  random from the outside.  This is not implemented by the openssl ca
> program.
>
> - Certificates are valid for at most 2 years (actually 825 days).
>
> - SHA-1 (and other weak algorithms such as MD5) are no longer
> permitted and
>  is already disappearing from Browser code.
>
> - RSA shorter than 2048 bits (and other weak settings such as equally
> short
>  DSA keys) are no longer permitted and is already disappearing from
> Browser
>  code.

How universal is ECDSA p-256 support?

>
> - If the certificate is issued to an e-mail address, that e-mail
> address must
>  also be listed as an rfc822Name in a "Subject Alternative Name"
> certificate
>  extension.

Which is also a problem in openssl.  You have to put the SAN into the
cnf file.  There are a number of hacks to do this from the command line.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Viktor Dukhovni

> On Aug 16, 2017, at 12:52 PM, Robert Moskowitz <[hidden email]> wrote:
>
> Which is also a problem in openssl.  You have to put the SAN into the cnf file.  There are a number of hacks to do this from the command line.

Yep.  For an approach that uses "bash" in-line files see:

   https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh#L95

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Robert Moskowitz


On 08/16/2017 01:12 PM, Viktor Dukhovni wrote:
>> On Aug 16, 2017, at 12:52 PM, Robert Moskowitz <[hidden email]> wrote:
>>
>> Which is also a problem in openssl.  You have to put the SAN into the cnf file.  There are a number of hacks to do this from the command line.
> Yep.  For an approach that uses "bash" in-line files see:
>
>     https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh#L95
>
I prefer something like this:

openssl req -new -sha256 -key domain.key -subj "/C=US/ST=CA/O=Acme,
Inc./CN=example.com"\
  -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf
"[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com"))\
  -out domain.csr

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Jakob Bohm-7
On 16/08/2017 19:54, Robert Moskowitz wrote:

>
>
> On 08/16/2017 01:12 PM, Viktor Dukhovni wrote:
>>> On Aug 16, 2017, at 12:52 PM, Robert Moskowitz <[hidden email]>
>>> wrote:
>>>
>>> Which is also a problem in openssl.  You have to put the SAN into
>>> the cnf file.  There are a number of hacks to do this from the
>>> command line.
>> Yep.  For an approach that uses "bash" in-line files see:
>>
>> https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh#L95
>>
> I prefer something like this:
>
> openssl req -new -sha256 -key domain.key -subj "/C=US/ST=CA/O=Acme,
> Inc./CN=example.com"\
>  -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf
> "[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com"))\
>  -out domain.csr
Another option is to use a config file that includes environment variables
in the relevant fields.

So it becomes something like
export FOREMAIL=[hidden email]
export FORUSER="Moe Madman"
export CERTFN=moe
openssl req -config /etc/cacfg/ca2017-mail.conf -newkey rsa:3072 -keyout
${CERTFN}.key -out ${CERTFN}.csr

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, 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-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Robert Moskowitz
In reply to this post by OpenSSL - User mailing list


On 08/16/2017 11:58 AM, Erwann Abalea via openssl-users wrote:

> Bonjour,
>
>> Le 16 août 2017 à 16:51, Jakob Bohm <[hidden email]> a écrit :
>>
>> On 16/08/2017 16:32, Tom Browder wrote:
>>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>     ➢ So, in summary, do I need to ensure cert serial numbers are
>>>     unique for my CA?
>>>
>>>     Why would you not?  The specifications require it, but those
>>>     specifications are for interoperability. If nobody is ever going
>>>     to see your certs, then who cares what’s in them?
>>>
>>>
>>> Well, I do like to abide by specs, and they will be used in various browsers, so I think I will continue the unique serial numbering.
>>>
>>> Thanks, Rich.
>> Modern browsers increasingly presume that such private CAs behave exactly
>> like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
>> the per-browser root CA inclusion programs (the administrative processes
>> that determine which CAs are listed in browsers by default).
>>
>> Among the relevant requirements now needed:
>>
>> - Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as standalone
>> numbers and as DER-encoded numbers.  Note that this is not the default in
>> the openssl ca program.
> There’s no such requirement. It MUST be at most 20 octets long.
>
>> - Serial numbers contain cryptographically strong random bits, currently at
>> least 64 random bits, though it is best if the entire serial number looks
>> random from the outside.  This is not implemented by the openssl ca program.
> It can be easily done by an external script. Generate a secret key for your CA for a 128bits block cipher, keep the monotonic counter, but instead of putting the value of the counter in the serial number, encrypt the counter with the key+cipher, and use the resulting cipher text as the serial number. Of course, increment the counter.
>
>> - Certificates are valid for at most 2 years (actually 825 days).
>>
>> - SHA-1 (and other weak algorithms such as MD5) are no longer permitted and
>> is already disappearing from Browser code.
>>
>> - RSA shorter than 2048 bits (and other weak settings such as equally short
>> DSA keys) are no longer permitted and is already disappearing from Browser
>> code.
>>
>> - If the certificate is issued to an e-mail address, that e-mail address must
>> also be listed as an rfc822Name in a "Subject Alternative Name" certificate
>> extension.
>>
>> - End user certificates must be issued from an Intermediary CA whose
>> certificate is is in turn issued from a longer term root CA.
> I doubt browsers impose this on purely private CAs.

But it is easy to do, and it allows you to store your root CA totally
offline.  Like on a mSD in a firebox (I am writing this into my guide).  
It also gives you flexibility to add another leaf for other sorts of
devices/usages.

For an RSA guide see:

https://jamielinux.com/docs/openssl-certificate-authority/introduction.html

For a roughish ECDSA guide see my recent effort:

http://www.htt-consult.com/pki.html  # this will be evolving as I add
more in (like looking into your seqNum recommendation).

>
>> - If revocation is implemented (it should be, just in case someone gets their
>> computer or other key storage hacked/stolen), it needs to support OCSP, but
>> should ideally do so without having the actual CA keys online (standard trick:
>> Issue 3-month non-revocable OCSP-signing certificates and provide the
>> corresponding private key to the server running the OCSP responder program).
>>   I would recommend to also implement traditional CRLs, since for smaller CAs
>> it is a better solution for browsers and servers that support it.
> Another requirement is that a TLS server certificate shall have its identity (FQDN) in the SAN extension. Use of the commonName attribute has been deprecated long ago.

Where is this documented?

thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Michel
>> Another requirement is that a TLS server certificate shall have its identity (FQDN) in the SAN extension. Use of the commonName attribute has been deprecated long ago.

> Where is this documented ?

Might be of interest : https://stackoverflow.com/questions/5935369/ssl-how-do-common-names-cn-and-subject-alternative-names-san-work-together


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

OpenSSL - User mailing list
In reply to this post by Robert Moskowitz
> There’s no such requirement. It MUST be at most 20 octets long.
    >
    >> - Serial numbers contain cryptographically strong random bits, currently at
    >> least 64 random bits, though it is best if the entire serial number looks
    >> random from the outside.  This is not implemented by the openssl ca program.

Edit apps/apps.h to change SERIAL_RAND_BITS and use the –create_serial flag.

I’ll be making a patch to do this more easily for master.

>Use of the commonName attribute has been deprecated long ago.
   
 >   Where is this documented?
   
RFC 2818 in 2000.  See aslo  https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Robert Moskowitz


On 08/16/2017 05:01 PM, Salz, Rich via openssl-users wrote:
>> There’s no such requirement. It MUST be at most 20 octets long.
>      >
>      >> - Serial numbers contain cryptographically strong random bits, currently at
>      >> least 64 random bits, though it is best if the entire serial number looks
>      >> random from the outside.  This is not implemented by the openssl ca program.
>
> Edit apps/apps.h to change SERIAL_RAND_BITS and use the –create_serial flag.
>
> I’ll be making a patch to do this more easily for master.

So we will have to wait for the next release or build our own...

Will there be some option to control the behavior?

>
>> Use of the commonName attribute has been deprecated long ago.
>      
>   >   Where is this documented?
>    
> RFC 2818 in 2000.  See aslo  https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo

No wonder I missed it.  My attention was off PKIX then as I was focused
on HIP...

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

OpenSSL - User mailing list
 
>    So we will have to wait for the next release or build our own...
 
Yes, as always.  Features go into the next release; fixes into existing ones.
 
>    Will there be some option to control the behavior?
 
Yes, like –rand_serial or some such in the ca and x509 commands.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Robert Moskowitz
In reply to this post by OpenSSL - User mailing list


On 08/16/2017 05:01 PM, Salz, Rich via openssl-users wrote:

>> There’s no such requirement. It MUST be at most 20 octets long.
>      >
>      >> - Serial numbers contain cryptographically strong random bits, currently at
>      >> least 64 random bits, though it is best if the entire serial number looks
>      >> random from the outside.  This is not implemented by the openssl ca program.
>
> Edit apps/apps.h to change SERIAL_RAND_BITS and use the –create_serial flag.
>
> I’ll be making a patch to do this more easily for master.
>
>> Use of the commonName attribute has been deprecated long ago.
>      
>   >   Where is this documented?
>    
> RFC 2818 in 2000.  See aslo  https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo


OK.  NOW I remember those debates in the PKIX sessions...

Boy is THIS rattling some old brain cells!


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Personal CA: are cert serial numbers critical?

Kyle Hamilton
In reply to this post by Tom Browder
Certificate serial numbers must be unique.  They need not be sequential or increasing.  (Mozilla's NSS will complain and refuse to work if there are duplicate serial numbers.)

I tend not to re-use keys, so I've found that putting 20 bytes (while clearing the high bit) of a digest of the SubjectPublicKeyInfo as the serial number works in that circumstance.  [if you leave the high bit set, then DER mandates that it be encoded with a leading 0x00 byte, which makes it 21 bytes... which can cause problems with things built for PKIX.]

-Kyle H

On Wed, Aug 16, 2017 at 6:24 AM, Tom Browder <[hidden email]> wrote:
Many years ago I started a CA for one group I manage for a private website, and now I want to update members' client certs for the stricter requirements for browsers.

My original cert generation was entirely automated including the following:

+ CN for each is an e-mail address for the member

+ the passphrase for each member's cert is determined from a pre-generated list by me, it will not change

I plan to tidy my automation before the issue of new certs, but I wonder how critical it is to ensure unique certificate serial numbers given that the certs are only used for us.  I'm not even sure I'll ever revoke any cert (they were issued to expire sometime in 2030).

So, in summary, do I need to ensure cert serial numbers are unique for my CA?

With warmest regards,

-Tom

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users