Increment certificate serial numbers randomly

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

Increment certificate serial numbers randomly

csa321
Hello,

We've generated our own CA for self-signing certificates.  The issue is that we package up the openssl install  for installation on multiple servers.  Therefore, the root CA we create is part of the package as well.

The problem is that since the CA cert will have the same serial number across all servers, any certificates issued from that CA, on different servers, end up having the same serial number.  This causes browser issues for obvious reasons.

Is there any way to control the incrementing of the serial number from the root CA so that it is completely random, instead of incrementing by 1, which it now defaults to?  That way we can have the same root CA installed on multiple machines and not run the chance of generating identical serial numbers for certificates.

Thanks in advance
Reply | Threaded
Open this post in threaded view
|

Re: Increment certificate serial numbers randomly

Walter H.
On 26.04.2014 05:52, csa321 wrote:
> We've generated our own CA for self-signing certificates.

>   The issue is that
> we package up the openssl install  for installation on multiple servers.
> Therefore, the root CA we create is part of the package as well.
>
the private key of the root CA should only exist on _ONE_ server; and as
a backup on a external media;
> The problem is that since the CA cert will have the same serial number
> across all servers,
copying doesn't change serial number
>   any certificates issued from that CA, on different
> servers, end up having the same serial number.
of course;
>   This causes browser issues
> for obvious reasons.
>
this is a design failure;  the certificates MUST all be signed on only
one server for this reason;
or each server must have its own root/intermediate CA;

> Is there any way to control the incrementing of the serial number from the
> root CA so that it is completely random,
No.




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

Re: Increment certificate serial numbers randomly

Viktor Dukhovni
On Sun, Apr 27, 2014 at 03:47:45PM +0200, Walter H. wrote:

> >Is there any way to control the incrementing of the serial number from the
> >root CA so that it is completely random,
>
> No.

Whether it is or is not a good idea to do store and use issuing CA
keys in multiple locations, it *is* possible to do so using a
somewhat lower layer interface than "openssl ca".  In particular,
a bash(1) script with the following function will be able to
statelessly sign a CSR:

  sign() {
      local digest=sha1  # Interoperable, use sha256 if desired
      local ca=$1; shift
      local cakey=$1; shift
      local days=$1; shift
      local reqin=$1; shift
      local certout=$1; shift

      exts=$(printf "%s\n%s\n%s\n%s\n%s\n[altnames]\n%s\n" \
          "subjectKeyIdentifier = hash" \
          "authorityKeyIdentifier = keyid, issuer" \
          "basicConstraints = CA:false" \
          "extendedKeyUsage = clientAuth, serverAuth" \
          "subjectAltName = @altnames" \
          "$(i=0; for n; do i=$((i+1)); printf "DNS.%d=%s\n" "$i" "$n"; done)"
      )

      openssl x509 -req -"$digest" -in "$reqin" -out "$certout" \
          -extfile <(printf "%s\n" "$exts") \
          -CA "$ca" -CAkey "$cakey" \
          -set_serial "0x$(openssl rand -hex 16)" \
          -days "$days"
  }

in a single call of the form:

      sign cacert.pem cakey.pem 365 csr.pem newcert.pem \
        foo.example.com bar.example.com ...

where the second line is a non-empty list of subject alternative
names to include.  The csr.pem file can be created using any suitable
tool, or via a similar approach:

  req() {
      local keyin=$1; shift
      local reqout=$1; shift
      local cn=$1; shift

      openssl req -new -sha1 -key "${keyin}" -out "$reqout" \
          -config <(printf "[req]\n%s\n%s\n%s\n[dn]\n%s\n" \
             "string_mask = utf8only" \
             "prompt = no" \
             "distinguished_name = dn" \
             "CN=$cn")
  }

  req key.pem csr.pem foo.example.com

Variants of this can be used that avoid generating intermediate
files, with the output of "req" piped in as the input to "sign"
which sends the certificate to stdout.

--
        Viktor.
______________________________________________________________________
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: Increment certificate serial numbers randomly

Mat Arge
In reply to this post by Walter H.
I agree with Walter, that it is not exactly good practise to have a CA key
lying around on multiple servers. But anyway, if you need to do it you have to
create the random serial number externally by some script and write it into
the serial file (as set in the openssl configuration file used) prior to
issuing the "openssl ca" command.

As a workaround if you do not want do do this, you could set different serial
number ranges on the various servers. Server1 starts at serial 1, Server2 at
0x010000 and so on. You'd still have incrementally growing serial numbers
(which is actually bad by itself) but from distinct ranges.

cheers
Mat

On Sunday 27. April 2014 15:47:45 you wrote:

> On 26.04.2014 05:52, csa321 wrote:
> > We've generated our own CA for self-signing certificates.
> >
> >   The issue is that
> >
> > we package up the openssl install  for installation on multiple servers.
> > Therefore, the root CA we create is part of the package as well.
>
> the private key of the root CA should only exist on _ONE_ server; and as
> a backup on a external media;
>
> > The problem is that since the CA cert will have the same serial number
> > across all servers,
>
> copying doesn't change serial number
>
> >   any certificates issued from that CA, on different
> >
> > servers, end up having the same serial number.
>
> of course;
>
> >   This causes browser issues
> >
> > for obvious reasons.
>
> this is a design failure;  the certificates MUST all be signed on only
> one server for this reason;
> or each server must have its own root/intermediate CA;
>
> > Is there any way to control the incrementing of the serial number from the
> > root CA so that it is completely random,
>
> No.

signature.asc (679 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Increment certificate serial numbers randomly

Larry Bugbee-2

On Apr 28, 2014, at 1:53 AM, Mat Arge <[hidden email]> wrote:

> You'd still have incrementally growing serial numbers
> (which is actually bad by itself) but from distinct ranges.

...or perhaps random within the range.



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

RE: Increment certificate serial numbers randomly

Michael Wojcik
In reply to this post by Mat Arge
> From: [hidden email] [mailto:owner-openssl-
> [hidden email]] On Behalf Of Mat Arge
> Sent: Monday, 28 April, 2014 04:54
>
> I agree with Walter, that it is not exactly good practise to have a CA key
> lying around on multiple servers. But anyway, if you need to do it you have
> to
> create the random serial number externally by some script and write it into
> the serial file (as set in the openssl configuration file used) prior to
> issuing the "openssl ca" command.

Or use something like Victor's script, rather than using the serial file.

> As a workaround if you do not want do do this, you could set different serial
> number ranges on the various servers. Server1 starts at serial 1, Server2 at
> 0x010000 and so on.

Depending on how large you want your serial numbers to get[1], and how many certificates you expect each node to sign, you could do something like using part or all of the MAC address of the host's first (non-loopback) NIC to define the range. That would avoid manually assigning ranges.

> You'd still have incrementally growing serial numbers
> (which is actually bad by itself) but from distinct ranges.

As Larry pointed out, there's no reason why you couldn't assign serial numbers pseudorandomly from within the range. You could keep simply keep a file of all the serials that host has assigned and keep generating numbers until you get a new one, or pick a value (pseudo)randomly from the ones that are still available using a shuffling or counting algorithm, or even just use a generator on the range.[2]

But in any event, there doesn't seem to be any reason why this couldn't be implemented with a little scripting, and it'd be better than simply picking serial numbers pseudorandomly across all the nodes and hoping the result was collision-free.

As for whether it's a good idea - again that depends ENTIRELY on your threat model. So many people seem to believe that their threat model applies universally.


[1] openssl x509 -serial_num uses s2i_ASN1_INTEGER to read the serial number specified on the command line, so it supports large values. I assume openssl ca does the same when reading the serial-number file, though I haven't actually checked.

[2] Of course, if you used a generator, an attacker who observed a few adjacent serial-number values could determine what parameters you used, and you'd be back to, in effect, incrementing serials. Whether that's a risk depends on your threat model.


--
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{,���
Reply | Threaded
Open this post in threaded view
|

RE: Increment certificate serial numbers randomly

Salz, Rich
In reply to this post by Mat Arge
If you are comfortable with the key existing (online?) in multiple places, make the serial number be a UUID treated as a BIGNUM.



--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [hidden email]; Twitter: RichSalz
:��I"Ϯ��r�m���� (���Z+�K�+����1���x ��h���[�z�(���Z+� ��f�y������f���h��)z{,���
Reply | Threaded
Open this post in threaded view
|

RE: Increment certificate serial numbers randomly

Michael Wojcik
> From: [hidden email] [mailto:owner-openssl-
> [hidden email]] On Behalf Of Salz, Rich
> Sent: Monday, 28 April, 2014 09:37
>
> If you are comfortable with the key existing (online?) in multiple places,
> make the serial number be a UUID treated as a BIGNUM.

Yes, that's a much simpler solution. It should be trivial to script that - just generate the UUID and write it to the serial-number file as "0x" followed by hex digits before invoking "openssl ca".

On Windows you can script generating the UUID with cscript, Powershell, or wmic - there are various examples online. On Linux, UNIX, and iOS, use uuidgen (you may have to grab the source and build it). uuidgen is also available for Windows, e.g. as part of Cygwin.

--
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{,���
Reply | Threaded
Open this post in threaded view
|

Re: Increment certificate serial numbers randomly

Jakob Bohm-7
In reply to this post by Mat Arge
On 4/28/2014 10:53 AM, Mat Arge wrote:

> I agree with Walter, that it is not exactly good practise to have a CA key
> lying around on multiple servers. But anyway, if you need to do it you have to
> create the random serial number externally by some script and write it into
> the serial file (as set in the openssl configuration file used) prior to
> issuing the "openssl ca" command.
>
> As a workaround if you do not want do do this, you could set different serial
> number ranges on the various servers. Server1 starts at serial 1, Server2 at
> 0x010000 and so on. You'd still have incrementally growing serial numbers
> (which is actually bad by itself) but from distinct ranges.
>

I seem to (vaguely) recall that there was once an option or standard for
using a certificate-contents-related hash as the serial number, but I
can't seem to find it right now.

As for the use of a widely shared private key, I have seen this sensibly
used for test certificates, where the (insecure) test CA is trusted
amongst systems configured in "test" mode, as long as all those systems
were from the vendor who originally set up this test root and
distributed the private key with their systems.

Use of certificates issued by this test root would result in a very
specific warning message summarizing the nature of those certificates,
while still allowing technical testing of the entire security system,
without exposing real (trusted) end entity private keys to insecure
test and compile environments.

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]
Reply | Threaded
Open this post in threaded view
|

Re: Increment certificate serial numbers randomly

Walter H.
On 29.04.2014 20:15, Jakob Bohm wrote:
> I seem to (vaguely) recall that there was once an option or standard for
> using a certificate-contents-related hash as the serial number, but I
> can't seem to find it right now.
Hi,
could you please try to find this; I would be interested in such - a way
of serial number that doesn't make
back reference in the number of certificates the CA has signed ...
Thanks,
Walter


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

Re: Increment certificate serial numbers randomly

David Johnston
> On 29.04.2014 20:15, Jakob Bohm wrote:
>> I seem to (vaguely) recall that there was once an option or standard for
>> using a certificate-contents-related hash as the serial number, but I
>> can't seem to find it right now.
> Hi,
> could you please try to find this; I would be interested in such - a way
> of serial number that doesn't make
> back reference in the number of certificates the CA has signed ...
> Thanks,
> Walter
>
>

This all seems unecessarily complex. Make the serial number a 256 bit or
greater true random number. There will be no collisions.

Making the serial number a function of the cert contents seems like a
really bad idea with potential consequences down the road.

______________________________________________________________________
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: Increment certificate serial numbers randomly

Walter H.
On 29.04.2014 21:38, [hidden email] wrote:
>
> This all seems unecessarily complex. Make the serial number a 256 bit or
> greater true random number. There will be no collisions.
the serial number has maximum length ..., 256 bit is quite too big ..


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

Re: Increment certificate serial numbers randomly

Tim Hudson
On 30/04/2014 6:05 AM, Walter H. wrote:
On 29.04.2014 21:38, [hidden email] wrote:

This all seems unecessarily complex. Make the serial number a 256 bit or
greater true random number. There will be no collisions.
the serial number has maximum length ..., 256 bit is quite too big ..


In X.509 terms the serial number is an ASN1 integer value so there is no real length limit.
It is also pretty common to see the output of a HASH operation used as a serial number in a certificate.
However in the context of everyone separately picking an RNG output value (on separate systems) there is no guarantee of zero collisions.

If you are installing the same "root" on multiple machines that don't coordinate then just auto-edit the serial file (if using the ca program) and put a unique prefix on the front. Perhaps just grab the machine MAC and add that in. And then the auto-incrementing handling will sort that out. The serial number format is simply a hex string value.

e.g. something like this could work (and there are better ways to do this - it is just to get you started down a path that may solve the original posters immediate issue)

ifconfig eth0 | grep HWaddr| awk '{print $NF}'| sed -e 's/://g'; echo "000000" > path-to-ca-serial-file

Tim.

Reply | Threaded
Open this post in threaded view
|

RE: Increment certificate serial numbers randomly

Michael Wojcik

All of these approaches have already been suggested in this thread. Is it really necessary that we go through them again?

 

Rich Salz's suggestion of using a UUID for the serial number makes collisions sufficiently improbable that the possibility can be ignored, and it's simpler than any of the other proposals.

 

Michael Wojcik
Technology Specialist, Micro Focus

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Tim Hudson
Sent: Tuesday, 29 April, 2014 16:32
To: [hidden email]
Subject: Re: Increment certificate serial numbers randomly

 

On 30/04/2014 6:05 AM, Walter H. wrote:

On 29.04.2014 21:38, [hidden email] wrote:


This all seems unecessarily complex. Make the serial number a 256 bit or
greater true random number. There will be no collisions.

the serial number has maximum length ..., 256 bit is quite too big ..


In X.509 terms the serial number is an ASN1 integer value so there is no real length limit.
It is also pretty common to see the output of a HASH operation used as a serial number in a certificate.
However in the context of everyone separately picking an RNG output value (on separate systems) there is no guarantee of zero collisions.

If you are installing the same "root" on multiple machines that don't coordinate then just auto-edit the serial file (if using the ca program) and put a unique prefix on the front. Perhaps just grab the machine MAC and add that in. And then the auto-incrementing handling will sort that out. The serial number format is simply a hex string value.

e.g. something like this could work (and there are better ways to do this - it is just to get you started down a path that may solve the original posters immediate issue)

ifconfig eth0 | grep HWaddr| awk '{print $NF}'| sed -e 's/://g'; echo "000000" > path-to-ca-serial-file

Tim.


Click here to report this email as spam.



This message has been scanned for malware by Websense. www.websense.com

Reply | Threaded
Open this post in threaded view
|

Re: Increment certificate serial numbers randomly

Nikolay Elenkov
On Wed, Apr 30, 2014 at 6:59 AM, Michael Wojcik
<[hidden email]> wrote:
> All of these approaches have already been suggested in this thread. Is it
> really necessary that we go through them again?
>
>

What hasn't been suggested is giving each server, etc. its own sub-CA signed by
the root. Then there won't be a need to have the root key at multiple places and
not problems with serial. Additionally, clients will only have to
install and trust
the root, which should make the whole thing easier to deploy.
______________________________________________________________________
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: Increment certificate serial numbers randomly

Walter H.
On 30.04.2014 03:57, Nikolay Elenkov wrote:
>
> What hasn't been suggested is giving each server, etc. its own sub-CA signed by
> the root. Then there won't be a need to have the root key at multiple places and
> not problems with serial. Additionally, clients will only have to
> install and trust
> the root, which should make the whole thing easier to deploy.
>
I already mentioned this solution (not me has the many servers):

"this is a design failure;  the certificates MUST all be signed on only
one server for this reason;
or each server must have its own root/intermediate CA;"

I want just come back to Jakob Bohm

"I seem to (vaguely) recall that there was once an option or standard for
using a certificate-contents-related hash as the serial number, but I
can't seem to find it right now."

if he has already found this - I'd use it for a totally different purpose;


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

Re: Increment certificate serial numbers randomly

Walter H.
In reply to this post by Tim Hudson
On 29.04.2014 22:32, Tim Hudson wrote:
On 30/04/2014 6:05 AM, Walter H. wrote:
On 29.04.2014 21:38, [hidden email] wrote:

This all seems unecessarily complex. Make the serial number a 256 bit or
greater true random number. There will be no collisions.
the serial number has maximum length ..., 256 bit is quite too big ..


In X.509 terms the serial number is an ASN1 integer value so there is no real length limit.
the maximum length is "defined" by the use of them; e.g. FF/TB accept only 128 bit or in other words,
they function properly with longer serial numbers;

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

Re: Increment certificate serial numbers randomly

Mat Arge
In reply to this post by Michael Wojcik
Some standards (like the CA/Browser Forum guidelines) request a certain amount
of entropy (like 20 bits) to be contained within the serial number. Is there
some sort of best-practice for incorporating this small amount of real random
data into a larger unique serial number?

cheers
Mat

On Tuesday 29. April 2014 21:59:10 you wrote:

> All of these approaches have already been suggested in this thread. Is it
> really necessary that we go through them again?
>
> Rich Salz's suggestion of using a UUID for the serial number makes
> collisions sufficiently improbable that the possibility can be ignored, and
> it's simpler than any of the other proposals.
>
> Michael Wojcik
> Technology Specialist, Micro Focus
>
>
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Tim Hudson Sent:
> Tuesday, 29 April, 2014 16:32
> To: [hidden email]
> Subject: Re: Increment certificate serial numbers randomly
>
> On 30/04/2014 6:05 AM, Walter H. wrote:
> On 29.04.2014 21:38, [hidden email]<mailto:[hidden email]> wrote:
>
>
> This all seems unecessarily complex. Make the serial number a 256 bit or
> greater true random number. There will be no collisions.
> the serial number has maximum length ..., 256 bit is quite too big ..
>
> In X.509 terms the serial number is an ASN1 integer value so there is no
> real length limit. It is also pretty common to see the output of a HASH
> operation used as a serial number in a certificate. However in the context
> of everyone separately picking an RNG output value (on separate systems)
> there is no guarantee of zero collisions.
>
> If you are installing the same "root" on multiple machines that don't
> coordinate then just auto-edit the serial file (if using the ca program)
> and put a unique prefix on the front. Perhaps just grab the machine MAC and
> add that in. And then the auto-incrementing handling will sort that out.
> The serial number format is simply a hex string value.
>
> e.g. something like this could work (and there are better ways to do this -
> it is just to get you started down a path that may solve the original
> posters immediate issue)
>
> ifconfig eth0 | grep HWaddr| awk '{print $NF}'| sed -e 's/://g'; echo
> "000000" > path-to-ca-serial-file
>
> Tim.
>
>
>
> Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to
> report this email as spam.
>
>
> This message has been scanned for malware by Websense. www.websense.com

signature.asc (679 bytes) Download Attachment