Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Kyle Hamilton]

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  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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Wouter Verhelst]

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

Re: [openssl-users] 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.


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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Salz, Rich via openssl-users]

 
>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

Re: [openssl-users] 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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Salz, Rich via openssl-users]

> 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

Re: [openssl-users] 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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Robert Moskowitz]

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

Bonjour,


Le 16 août 2017 à 16:51, Jakob Bohm  a écrit :

On 16/08/2017 16:32, Tom Browder wrote:

On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users > 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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Erwann Abalea via openssl-users]

Bonjour,

> Le 16 août 2017 à 16:51, Jakob Bohm  a écrit :
> 
> On 16/08/2017 16:32, Tom Browder wrote:
>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users 
>> > 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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Jakob Bohm]

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  
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=m...@example.com
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

Re: [openssl-users] 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  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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Viktor Dukhovni]

> On Aug 16, 2017, at 12:52 PM, Robert Moskowitz  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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Robert Moskowitz]

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 
> 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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Gregory Sloop]

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 
>> > 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: gr...@sloop.net
http://www.sloop.net
- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Jakob Bohm]

On 16/08/2017 16:32, Tom Browder wrote:
On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users 
> 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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Tom Browder]

On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users <
openssl-users@openssl.org> 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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Tom Browder]

On Wed, Aug 16, 2017 at 08:32 Michael Ströder  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

Re: [openssl-users] Personal CA: are cert serial numbers critical?

[Salz, Rich via openssl-users]

➢ 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

Re: [openssl-users] 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.



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users