Quick eyeball requested - self generate openssl certs/CA

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

Quick eyeball requested - self generate openssl certs/CA

Tim Watts-2
Hi folks,

I'm setting up a new CA/SSL infrastructure for work - the CA is self
signed and all SSL certs (mostly server certs rather than client certs)
will be signed off against this CA.

I've just made the effort to try to actually understand SSL a bit better
rather than monkey churning brokens certs out - so I'd really value a
quick eyeball of my config and some text dumps of sample certs if anyone
has a mo.

Revocation crl would be published in this example at:

http://www.example.com/ssl/CA-example.com.crl

I do apologise - it's a long post. I'm just not totally sure if I have
the correct attributes and extensions - and whether it meets the
requirements of a v3 SSL cert (I think it does). Is 4096 bit key and
sha1 a good choice?

And is the revocation bit done correctly (assuming I actually maintain a
CRL from openssl ca -gencrl at the url above?

Here goes:

================ config =====================
We use [v3_ca] for the CA, [server_cert] for server certs,
[client_cert] for clients - Sorry slight line wrap

The common name varies by the cert, but the rest is constant.
=============================================
[ ca ]
default_ca = CA_default

[ CA_default ]
dir = /home/tw/WORK/Devel/SSL-Certs
database = /home/tw/WORK/Devel/SSL-
Certs/.data/index.txt
new_certs_dir = /home/tw/WORK/Devel/SSL-Certs/.data
serial = /home/tw/WORK/Devel/SSL-Certs/.data/serial
RANDFILE = /home/tw/WORK/Devel/SSL-Certs/.data/.rand
x509_extensions = server_cert
default_days = 395
default_crl_days = 395
default_md = sha1
preserve = no
policy = policy
unique_subject = yes
email_in_dn = no

[ server_cert ]
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Certificate"
nsCaRevocationUrl = http://www.example.com/ssl/CA-
example.com.crl
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
issuerAltName = issuer:copy
subjectAltName = email:copy

[ client_cert ]
basicConstraints = CA:FALSE
nsCertType = client, email, objsign
nsComment = "OpenSSL Generated Certificate"
nsCaRevocationUrl = http://www.example.com/ssl/example.com.crl
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
issuerAltName = issuer:copy
subjectAltName = email:copy
keyUsage = digitalSignature, keyEncipherment

[ policy ]
countryName = supplied
stateOrProvinceName = supplied
organizationName = supplied
organizationalUnitName = supplied
commonName = supplied
emailAddress = optional

[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca
string_mask = nombstr
req_extensions = v3_req

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = GB
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = London
localityName = Locality Name (eg, city)
localityName_default = Trafalger Square
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Exampel Widgets Inc
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = Systems Group
commonName = Common Name
commonName_default = example.com
commonName_max = 64
emailAddress = Email Address
emailAddress_default = [hidden email]
emailAddress_max = 40

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:true
nsCertType = sslCA, emailCA
issuerAltName = issuer:copy
nsComment = "OpenSSL Generated Certificate"
nsCaRevocationUrl = http://www.example.com/ssl/CA-
example.com.crl
subjectAltName = email:copy
keyUsage = critical, keyCertSign, cRLSign

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature,
keyEncipherment

[ req_attributes ]

[ crl_ext ]
authorityKeyIdentifier = keyid:always,issuer:always
==================== End config ==============================

========== Sample CA text dump ===============================

generated with:

openssl req -new -batch -keyform PEM -outform PEM -config
.temp/sslconfig.cnf -out .temp/CA-example.com.csr -keyout .temp/CA-
example.com.key -extensions v3_ca -sha1

and

openssl ca -config .temp/sslconfig.cnf -create_serial -out .temp/CA-
example.com.crt -days 3660 -batch -keyfile .temp/CA-example.com.key -
selfsign -extensions v3_ca -in .temp/CA-example.com.csr

==============================================================

% openssl x509 -in certs/CA-example.com.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1048576 (0x100000)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, ST=London, O=Exampel Widgets Inc, OU=Systems Group,
CN=example.com/emailAddress=[hidden email]
Validity
Not Before: May 19 08:43:17 2011 GMT
Not After : May 26 08:43:17 2021 GMT
Subject: C=GB, ST=London, O=Exampel Widgets Inc, OU=Systems Group,
CN=example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (4096 bit)
Modulus (4096 bit):
<snip hex> Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
4D:33:FC:AD:66:76:FB:9F:13:B1:77:1E:C4:FC:03:0B:3D:C8:BB:33
X509v3 Authority Key Identifier:
keyid:4D:33:FC:AD:66:76:FB:9F:13:B1:77:1E:C4:FC:03:0B:3D:C8:BB:33
DirName:/C=GB/ST=London/O=Exampel Widgets Inc/OU=Systems
Group/CN=example.com/emailAddress=[hidden email]
serial:10:00:00

X509v3 Basic Constraints:
CA:TRUE
Netscape Cert Type:
SSL CA, S/MIME CA
X509v3 Issuer Alternative Name:
<EMPTY>

Netscape Comment:
OpenSSL Generated Certificate
Netscape CA Revocation Url:
http://www.example.com/ssl/CA-example.com.crl
X509v3 Subject Alternative Name:
email:[hidden email]
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
Signature Algorithm: sha1WithRSAEncryption
<snip hex>
==================== End CA dump ==============================

==================== Server cert ==============================

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1048577 (0x100001)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, ST=London, O=Exampel Widgets Inc, OU=Systems Group,
CN=example.com
Validity
Not Before: May 19 08:45:46 2011 GMT
Not After : May 18 08:45:46 2012 GMT
Subject: C=GB, ST=London, O=Exampel Widgets Inc, OU=Systems Group,
CN=www.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (4096 bit)
Modulus (4096 bit):
<snip hex>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Certificate
Netscape CA Revocation Url:
http://www.example.com/ssl/CA-www.example.com.crl
X509v3 Subject Key Identifier:
DE:96:E9:01:C8:6E:70:53:56:07:E9:0A:B4:AA:34:7B:47:51:34:31
X509v3 Authority Key Identifier:
keyid:4D:33:FC:AD:66:76:FB:9F:13:B1:77:1E:C4:FC:03:0B:3D:C8:BB:33
DirName:/C=GB/ST=London/O=Exampel Widgets Inc/OU=Systems
Group/CN=example.com/emailAddress=[hidden email]
serial:10:00:00

X509v3 Issuer Alternative Name:
email:[hidden email]
X509v3 Subject Alternative Name:
email:[hidden email]
Signature Algorithm: sha1WithRSAEncryption
<snip hex>
-----BEGIN CERTIFICATE-----
<snip>

==================== End server cert ==========================

==================== Client cert ==============================

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1048578 (0x100002)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, ST=London, O=Exampel Widgets Inc, OU=Systems Group,
CN=example.com
Validity
Not Before: May 19 08:47:26 2011 GMT
Not After : May 18 08:47:26 2012 GMT
Subject: C=GB, ST=London, O=Exampel Widgets Inc, OU=Systems Group,
CN=marky.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (4096 bit)
Modulus (4096 bit):
<snip hex> Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME, Object Signing
Netscape Comment:
OpenSSL Generated Certificate
Netscape CA Revocation Url:
http://www.example.com/ssl/marky.example.com.crl
X509v3 Subject Key Identifier:
71:E4:02:DA:96:E9:8A:B6:48:89:4D:B9:B7:8C:64:0B:CD:9B:81:F3
X509v3 Authority Key Identifier:
keyid:4D:33:FC:AD:66:76:FB:9F:13:B1:77:1E:C4:FC:03:0B:3D:C8:BB:33
DirName:/C=GB/ST=London/O=Exampel Widgets Inc/OU=Systems
Group/CN=example.com/emailAddress=[hidden email]
serial:10:00:00

X509v3 Issuer Alternative Name:
email:[hidden email]
X509v3 Subject Alternative Name:
email:[hidden email]
X509v3 Key Usage:
Digital Signature, Key Encipherment
Signature Algorithm: sha1WithRSAEncryption
<snip hex>
-----BEGIN CERTIFICATE-----
<snip>
==================== End client cert ==========================

Many thanks for any comments!

Cheers,

Tim

--
Tim Watts
______________________________________________________________________
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: Quick eyeball requested - self generate openssl certs/CA

Jeffrey Walton-3
On Thu, May 19, 2011 at 5:44 AM, Tim Watts <[hidden email]> wrote:

> Hi folks,
>
> I'm setting up a new CA/SSL infrastructure for work - the CA is self signed
> and all SSL certs (mostly server certs rather than client certs) will be
> signed off against this CA.
>
> I've just made the effort to try to actually understand SSL a bit better
> rather than monkey churning brokens certs out - so I'd really value a quick
> eyeball of my config and some text dumps of sample certs if anyone has a mo.
>
> Revocation crl would be published in this example at:
>
> http://www.example.com/ssl/CA-example.com.crl
>
> I do apologise - it's a long post. I'm just not totally sure if I have the
> correct attributes and extensions - and whether it meets the requirements of
> a v3 SSL cert (I think it does). Is 4096 bit key and sha1 a good choice?
>
> And is the revocation bit done correctly (assuming I actually maintain a CRL
> from openssl ca -gencrl at the url above?
>
>
> [SNIP]

> I'm setting up a new CA/SSL infrastructure for work
> ...
> and whether it meets the requirements of a v3 SSL cert
> (I think it does). Is 4096 bit key and sha1 a good choice?
SHA-1 is not a good choice here. You are exceeding 128 bits of
security with the 4096 key, but only offering ~50 bits of security for
authentication (SHA has an ideal level of 80 bits, but it has been
reduced). You would probably want to use SHA-256. As an attacker,
would you try to factor the modulus (which should take over 2^128
work, or swap in a key and sign it as the CA (at a cost of 2^50)?

Jeff
______________________________________________________________________
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: Quick eyeball requested - self generate openssl certs/CA

Tim Watts-2
On 19/05/11 11:53, Jeffrey Walton wrote:

>> I'm setting up a new CA/SSL infrastructure for work
>> ...
>> and whether it meets the requirements of a v3 SSL cert
>> (I think it does). Is 4096 bit key and sha1 a good choice?
> SHA-1 is not a good choice here. You are exceeding 128 bits of
> security with the 4096 key, but only offering ~50 bits of security for
> authentication (SHA has an ideal level of 80 bits, but it has been
> reduced). You would probably want to use SHA-256. As an attacker,
> would you try to factor the modulus (which should take over 2^128
> work, or swap in a key and sign it as the CA (at a cost of 2^50)?
>
> Jeff

Hi Jeff,

Thank you for that - I'm a sysadmin, but I am not managing to keep up
with encryption theory/practise recently.

That is a very valuable tip - I'll swap it over to SHA-256.

[Rest of query still stands for anyone kind enough to be able to comment
on other aspects].

All the best,

Tim
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Erwann ABALEA
In reply to this post by Tim Watts-2
Bonjour,

Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
> I do apologise - it's a long post. I'm just not totally sure if I
> have the correct attributes and extensions - and whether it meets
> the requirements of a v3 SSL cert (I think it does). Is 4096 bit key
> and sha1 a good choice?

SHA1 is still tolerated, but being slowly obsolete. You can still use
it if your serial numbers have some randomness, which is not the case
here. Either use one member of the SHA2 family, or generate random
serial numbers.

> And is the revocation bit done correctly (assuming I actually
> maintain a CRL from openssl ca -gencrl at the url above?

All the "ns*" extensions are deprecated, and shouldn't be used
anymore. The nsCaRevocationUrl extension should be replaced by this:
crlDistributionPoints = URI:http://www.example.com/ssl/CA-example.com.crl

You don't need to place a CRLDP extension in the root CA certificate
(a root can't really revoke itself).

You forgot to place the keyUsage extension in your server
certificates.

The issuerAltName extension is useless as stated (I'd say it's also
useless in general, but I won't argue).

I'd set the critical flag for the basicConstraints extension (both CA
and end-users (server+user)).

--
Erwann ABALEA <[hidden email]>
Département R&D
KEYNECTIS
-----
Your mouse has moved. Please reboot to continue.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Tim Watts-2
Bonjour :)

On 19/05/11 13:03, Erwann ABALEA wrote:

> Bonjour,
>
> Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
>> I do apologise - it's a long post. I'm just not totally sure if I
>> have the correct attributes and extensions - and whether it meets
>> the requirements of a v3 SSL cert (I think it does). Is 4096 bit key
>> and sha1 a good choice?
>
> SHA1 is still tolerated, but being slowly obsolete. You can still use
> it if your serial numbers have some randomness, which is not the case
> here. Either use one member of the SHA2 family, or generate random
> serial numbers.

Hi Erwann,

Thanks for that. I'm not sure how to do random serials (I let openssl
manage those) but it interesting to know it makes a difference.

>> And is the revocation bit done correctly (assuming I actually
>> maintain a CRL from openssl ca -gencrl at the url above?
>
> All the "ns*" extensions are deprecated, and shouldn't be used
> anymore.

I had a bad feeling about those, but when I searched on google for "CRL
revocation URL" I didn't find anything else. Again, thanks - exactly the
advice I am after :)

> The nsCaRevocationUrl extension should be replaced by this:
> crlDistributionPoints = URI:http://www.example.com/ssl/CA-example.com.crl

OK - cool. Should I support both do you think for backwards compatibility?

[1] See point below

> You don't need to place a CRLDP extension in the root CA certificate
> (a root can't really revoke itself).

OK. Wasn't sure about that...

> You forgot to place the keyUsage extension in your server
> certificates.

Oops. Ta.

> The issuerAltName extension is useless as stated (I'd say it's also
> useless in general, but I won't argue).

What should it be in this context?

> I'd set the critical flag for the basicConstraints extension (both CA
> and end-users (server+user)).
>

OK -will do :)

Many many thanks for all this :)

This is one of those jobs that I assign the "want to do it right" flag
too - I have a 100 servers that eventually need new certs (though I will
probably be forced to use a wildcard CN on most of them as many do name
based virtual hosting on apache - yes I know, the RFCs only mention
wildcard CNs in the context of a few services and not specifically
HTTPS, but what can you do...)

Cheers,

Tim

[1]

I read an interesting blog by a google employee on the issue of CRLs and
avoiding the whole issue by setting up automatic distribution of very
short time-to-live certs:

http://www.imperialviolet.org/2011/03/18/revocation.html

(Adam is an ex-student of the uni I used to work at - a very sharp
fellow indeed).

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Erwann ABALEA
Bonjour Tim,

Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
> On 19/05/11 13:03, Erwann ABALEA wrote:
[...]

> >SHA1 is still tolerated, but being slowly obsolete. You can still use
> >it if your serial numbers have some randomness, which is not the case
> >here. Either use one member of the SHA2 family, or generate random
> >serial numbers.
>
> Hi Erwann,
>
> Thanks for that. I'm not sure how to do random serials (I let
> openssl manage those) but it interesting to know it makes a
> difference.

This how I do this:
 - in the setup phase, after having generated the CA private key,
   generate a secret key (16 random bytes taken from /dev/urandom will
   suffice), and place this key into <CAdir>/private/secretkey; I also
   create a file named "counter", in the same directory as the
   "serial" one, and init it with an "echo 1 > ..../counter"
 - when I want to sign a certificate, do this:
     SECRETKEY=`od -t x1 -A n DIRECTORY/private/secretkey | sed 's/ //g' | tr 'a-f' 'A-F'`
     COUNTER=`cat DIRECTORY/counter`
     echo `expr $COUNTER + 1` > DIRECTORY/counter
     SERIALHEX=`echo -n $COUNTER | openssl enc -e -K $SECRETKEY -iv 00000000000000000000000000000000 -aes-128-cbc | od -t x1 -A n | sed 's/ //g' | tr 'a-f' 'A-F'`
     SERIAL=`(echo ibase=16; echo $SERIALHEX) | bc -l`
   and then either:
    - use "-set_serial $SERIAL" if you produce a self-signed
      certificate with the "openssl req" command
    - do "echo $SERIAL > DIRECTORY/serial", and run the "openssl ca"
      command as usual

That way, the serial number is random for the outside, is guaranted to
be unique, and stays deterministic for you (decrypt it with your
secret key, and you'll be able to know which "number" it is, if you
need).

Using random serial numbers is interesting if the hash function is no
more collision resistant (MD5 isn't, SHA1 is still up, but not for so
long).

[...]
> >The nsCaRevocationUrl extension should be replaced by this:
> >crlDistributionPoints = URI:http://www.example.com/ssl/CA-example.com.crl
>
> OK - cool. Should I support both do you think for backwards compatibility?

Just use crlDistributionPoints, everybody wanting to download a CRL
will do this from this extension. This "ns" (netscape) extension is of
no use.

> >The issuerAltName extension is useless as stated (I'd say it's also
> >useless in general, but I won't argue).
>
> What should it be in this context?

Don't use this extension, unless you want to name your CA with another
name as the one given in its issuerName :)

[...]

> This is one of those jobs that I assign the "want to do it right"
> flag too - I have a 100 servers that eventually need new certs
> (though I will probably be forced to use a wildcard CN on most of
> them as many do name based virtual hosting on apache - yes I know,
> the RFCs only mention wildcard CNs in the context of a few services
> and not specifically HTTPS, but what can you do...)
>
> Cheers,
>
> Tim
>
> I read an interesting blog by a google employee on the issue of CRLs
> and avoiding the whole issue by setting up automatic distribution of
> very short time-to-live certs:
>
> http://www.imperialviolet.org/2011/03/18/revocation.html
>
> (Adam is an ex-student of the uni I used to work at - a very sharp
> fellow indeed).

That's an interesting point. The author could have given more detailed
information, as some browsers use the native OS crypto API (for
example IE, Chrome or Safari), or use NSS when nothing is provided by the
OS (Chrome on Linux), or use their own crypto API (NSS for Firefox,
something else for Opera). The revocation validation is generally
performed by the used crypto API. To simplify it a little more, EV
behaviour is not imposed by this API, and is proprietary to the
browser.

You can surely deliver short-lived certificates, but you'll have to
renew them more often, and deploy them, etc. That's a lot of work :)
This solution has also be mentioned in the Mozilla CA Policy group.

--
Erwann ABALEA <[hidden email]>
Département R&D
KEYNECTIS
-----
If at first you don't succeed; Blame everyone else
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Tim Watts-2
On 19/05/11 14:48, Erwann ABALEA wrote:
> Bonjour Tim,
>
> Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:

>> Thanks for that. I'm not sure how to do random serials (I let
>> openssl manage those) but it interesting to know it makes a
>> difference.
>
> This how I do this:
>   - in the setup phase, after having generated the CA private key,
>     generate a secret key (16 random bytes taken from /dev/urandom will
>     suffice), and place this key into<CAdir>/private/secretkey; I also
>     create a file named "counter", in the same directory as the
>     "serial" one, and init it with an "echo 1>  ..../counter"
>   - when I want to sign a certificate, do this:
>       SECRETKEY=`od -t x1 -A n DIRECTORY/private/secretkey | sed 's/ //g' | tr 'a-f' 'A-F'`
>       COUNTER=`cat DIRECTORY/counter`
>       echo `expr $COUNTER + 1`>  DIRECTORY/counter
>       SERIALHEX=`echo -n $COUNTER | openssl enc -e -K $SECRETKEY -iv 00000000000000000000000000000000 -aes-128-cbc | od -t x1 -A n | sed 's/ //g' | tr 'a-f' 'A-F'`
>       SERIAL=`(echo ibase=16; echo $SERIALHEX) | bc -l`
>     and then either:
>      - use "-set_serial $SERIAL" if you produce a self-signed
>        certificate with the "openssl req" command
>      - do "echo $SERIAL>  DIRECTORY/serial", and run the "openssl ca"
>        command as usual

Hi Erwann,


I presume there is a slight possibility of a serial number clash with
that? Not that it's a problem, but it would be wise to check index.txt
to see if the number has been used before?

>>> The issuerAltName extension is useless as stated (I'd say it's also
>>> useless in general, but I won't argue).
>>
>> What should it be in this context?

> Don't use this extension, unless you want to name your CA with another
> name as the one given in its issuerName :)

Yes - I understand now - ta!

>> I read an interesting blog by a google employee on the issue of CRLs
>> and avoiding the whole issue by setting up automatic distribution of
>> very short time-to-live certs:
>>
>> http://www.imperialviolet.org/2011/03/18/revocation.html
>>
>> (Adam is an ex-student of the uni I used to work at - a very sharp
>> fellow indeed).
>
> That's an interesting point. The author could have given more detailed
> information, as some browsers use the native OS crypto API (for
> example IE, Chrome or Safari), or use NSS when nothing is provided by the
> OS (Chrome on Linux), or use their own crypto API (NSS for Firefox,
> something else for Opera). The revocation validation is generally
> performed by the used crypto API. To simplify it a little more, EV
> behaviour is not imposed by this API, and is proprietary to the
> browser.
>
> You can surely deliver short-lived certificates, but you'll have to
> renew them more often, and deploy them, etc. That's a lot of work :)
> This solution has also be mentioned in the Mozilla CA Policy group.
>

I have a masterplan for that :) I have, out of necessity, a very secure
"gold server" that has access to everything else (it will become the
master Kerberos server one day and also needs to auto distribute
kerberos keys when that happens). It is extremely well protected - which
means the issue of caching the CA passphrase on it is moot (if anyone
hacks that server, they own everything anyway - SSL will be the least of
our problems - a point that is generally true of any master
authentication or config management server even without the additional
abilities this one has).

The infrastructure I envisage is one where a database will have a record
of all SSL enabled services and cert/key file locations plus CN
information - which makes it practical to run and distribute by itself -
which then makes Adam's idea viable.

Not that our infrastructure actually needs bomb proof SSL (we are not a
big target and we don't have any financial information to protect) - but
it is interesting academically.

Cheers,

Tim
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Erwann ABALEA
Bonjour Tim,

Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:

> On 19/05/11 14:48, Erwann ABALEA wrote:
> >Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
>
> >>Thanks for that. I'm not sure how to do random serials (I let
> >>openssl manage those) but it interesting to know it makes a
> >>difference.
> >
> >This how I do this:
> >  - in the setup phase, after having generated the CA private key,
> >    generate a secret key (16 random bytes taken from /dev/urandom will
> >    suffice), and place this key into<CAdir>/private/secretkey; I also
> >    create a file named "counter", in the same directory as the
> >    "serial" one, and init it with an "echo 1>  ..../counter"
> >  - when I want to sign a certificate, do this:
> >      SECRETKEY=`od -t x1 -A n DIRECTORY/private/secretkey | sed 's/ //g' | tr 'a-f' 'A-F'`
> >      COUNTER=`cat DIRECTORY/counter`
> >      echo `expr $COUNTER + 1`>  DIRECTORY/counter
> >      SERIALHEX=`echo -n $COUNTER | openssl enc -e -K $SECRETKEY -iv 00000000000000000000000000000000 -aes-128-cbc | od -t x1 -A n | sed 's/ //g' | tr 'a-f' 'A-F'`
> >      SERIAL=`(echo ibase=16; echo $SERIALHEX) | bc -l`
> >    and then either:
> >     - use "-set_serial $SERIAL" if you produce a self-signed
> >       certificate with the "openssl req" command
> >     - do "echo $SERIAL>  DIRECTORY/serial", and run the "openssl ca"
> >       command as usual
>
> I presume there is a slight possibility of a serial number clash
> with that? Not that it's a problem, but it would be wise to check
> index.txt to see if the number has been used before?

Really, no. A counter is encrypted, and the result of the encryption
is the serial number.

If you imagine a collision in this serial number generation scheme,
then it means that a ciphertext (serial number) can be decrypted into
2 different plaintexts (counter). That's impossible if the secret key
is constant.

The problem with this scheme is that it doesn't deal well with
parallel certificate signatures. You have one shared information that
must be incremented in an atomic way. But for a "Junk CA" (that's how
I call the set of scripts I use), that's not a problem.

You could have used another scheme:
 - generate 16 random bytes
 - place them in the serialNumber
With such a scheme, yes, a collision could occur, and you should check
the index.txt file first.

Beware of the "ca" command line tool if you have a large population. I
wanted to use it for a massive certificate generation (in order to
fill an LDAP directory), and the time taken to generate a certificate
goes larger with the number of generated certificates (it must load
the file into memory, check if the given name either doesn't exist or
exists only with revoked or expired certificates, extend the list, and
finally write it again onto disk).

[...]

> >You can surely deliver short-lived certificates, but you'll have to
> >renew them more often, and deploy them, etc. That's a lot of work :)
> >This solution has also be mentioned in the Mozilla CA Policy group.
>
> I have a masterplan for that :) I have, out of necessity, a very
> secure "gold server" that has access to everything else (it will
> become the master Kerberos server one day and also needs to auto
> distribute kerberos keys when that happens). It is extremely well
> protected - which means the issue of caching the CA passphrase on it
> is moot (if anyone hacks that server, they own everything anyway -
> SSL will be the least of our problems - a point that is generally
> true of any master authentication or config management server even
> without the additional abilities this one has).
>
> The infrastructure I envisage is one where a database will have a
> record of all SSL enabled services and cert/key file locations plus
> CN information - which makes it practical to run and distribute by
> itself - which then makes Adam's idea viable.

Then this deployment server will be your SPOF :)

--
Erwann ABALEA <[hidden email]>
Département R&D
KEYNECTIS
-----
``It's nice to be important, but it's important to be nice.''
                                     Anon.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Tim Watts-2
On 19/05/11 16:09, Erwann ABALEA wrote:
> Bonjour Tim,
>

Hi Erwann,

>> I presume there is a slight possibility of a serial number clash
>> with that? Not that it's a problem, but it would be wise to check
>> index.txt to see if the number has been used before?
>
> Really, no. A counter is encrypted, and the result of the encryption
> is the serial number.
>
> If you imagine a collision in this serial number generation scheme,
> then it means that a ciphertext (serial number) can be decrypted into
> 2 different plaintexts (counter). That's impossible if the secret key
> is constant.
>
> The problem with this scheme is that it doesn't deal well with
> parallel certificate signatures. You have one shared information that
> must be incremented in an atomic way. But for a "Junk CA" (that's how
> I call the set of scripts I use), that's not a problem.

OK - I see now - thanks.

> You could have used another scheme:
>   - generate 16 random bytes
>   - place them in the serialNumber
> With such a scheme, yes, a collision could occur, and you should check
> the index.txt file first.

OK - that has straightened out my thinking :)

> Beware of the "ca" command line tool if you have a large population. I
> wanted to use it for a massive certificate generation (in order to
> fill an LDAP directory), and the time taken to generate a certificate
> goes larger with the number of generated certificates (it must load
> the file into memory, check if the given name either doesn't exist or
> exists only with revoked or expired certificates, extend the list, and
> finally write it again onto disk).

Interesting...

>> The infrastructure I envisage is one where a database will have a
>> record of all SSL enabled services and cert/key file locations plus
>> CN information - which makes it practical to run and distribute by
>> itself - which then makes Adam's idea viable.
>
> Then this deployment server will be your SPOF :)
>

Only in a limited sense :) I have worked with such a system before (in
fact I am merely reimplementing - except for the SSL bit which would be
new).

What actually happens is: kerberos is slaved to a couple of other
machines in the usual way. The master config datastore is backed up (for
a high volume environment it is actually hosted on another server
anyway) and backed up.

The ability to do root ssh is lost if the master gold server dies, but
that doesn't stop anything working (for a time anyway until updates are
needed to the other hosts) and the config system can be restored (or is
still working on another host) and can be used to ship out a fresh
.ssh/authorized_keys file to all the hosts.

Only the SSL datastore is vulnerable as you probably don't want that
backed up in the conventional manner (unless you separate the master
passphrase cache out and secure all the probably passphrase-less keys).
But given you need two or more kerberos (or could be LDAP) auth servers,
all of which *must* be secure[1], you could have one replicate (back up)
its SSL store to the other.

[1] I take the view that if you root a kerberos server, you have the
ability to alter any principle so you can own the rest of the systems -
the same is true of a config master (whether it be puppet or a home
grown system like mine). So giving it overt ability to do other things
is not an additional risk.

Cheers,

Tim

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Peter Sylvester-3
In reply to this post by Erwann ABALEA


> The problem with this scheme is that it doesn't deal well with
> parallel certificate signatures. You have one shared information that
> must be incremented in an atomic way. But for a "Junk CA" (that's how
> I call the set of scripts I use), that's not a problem.
another approach is to take the value of 'time' (the current second)
and append to it the current process number, and, in case of
several machines, some number indicating the id of the machine.

instead of the process number, any other method to ensure uniqueness
within a second may be used.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Tim Watts-2
On 19/05/11 16:46, Peter Sylvester wrote:

>
>
>> The problem with this scheme is that it doesn't deal well with
>> parallel certificate signatures. You have one shared information that
>> must be incremented in an atomic way. But for a "Junk CA" (that's how
>> I call the set of scripts I use), that's not a problem.
> another approach is to take the value of 'time' (the current second)
> and append to it the current process number, and, in case of
> several machines, some number indicating the id of the machine.
>
> instead of the process number, any other method to ensure uniqueness
> within a second may be used.

Ah yes - that would guarantee a non repeating unpredictable sequence.

I was confuse initially as I did not realise the serial number could be
so big (16 bytes was it?).

Cheers

Tim
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Erwann ABALEA
Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:

> On 19/05/11 16:46, Peter Sylvester wrote:
> >another approach is to take the value of 'time' (the current second)
> >and append to it the current process number, and, in case of
> >several machines, some number indicating the id of the machine.
> >
> >instead of the process number, any other method to ensure uniqueness
> >within a second may be used.
>
> Ah yes - that would guarantee a non repeating unpredictable sequence.
>
> I was confuse initially as I did not realise the serial number could
> be so big (16 bytes was it?).

20 bytes max, for the RFC5280.

--
Erwann ABALEA <[hidden email]>
Département R&D
KEYNECTIS
-----
If you never try anything new, you'll miss out on many of life's great
disappointments.
                                      Demotivators, 2002 calendar
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Tim Watts-2
On 19/05/11 17:38, Erwann ABALEA wrote:

> Hodie XIV Kal. Iun. MMXI, Tim Watts scripsit:
>> On 19/05/11 16:46, Peter Sylvester wrote:
>>> another approach is to take the value of 'time' (the current second)
>>> and append to it the current process number, and, in case of
>>> several machines, some number indicating the id of the machine.
>>>
>>> instead of the process number, any other method to ensure uniqueness
>>> within a second may be used.
>>
>> Ah yes - that would guarantee a non repeating unpredictable sequence.
>>
>> I was confuse initially as I did not realise the serial number could
>> be so big (16 bytes was it?).
>
> 20 bytes max, for the RFC5280.
>

OK - wow.

I think I might add some "randomness" into mine - seems easy enough. I
won't pretend I fully understand why - mostly because I wasn't clear why
the serial is important.

I understand the merits of "random" TCP sequence numbers though - but
the reason for those is a little more obvious.

That's not a request for a detailed explanation, BTW - I'm happy to take
it on trust from you experts :)

Thanks!

Tim
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Michael S. Zick-4
On Thu May 19 2011, Tim Watts wrote:
> I think I might add some "randomness" into mine - seems easy enough. I
> won't pretend I fully understand why - mostly because I wasn't clear why
> the serial is important.
>

If your CPU has a 'time stamp register' (cycle counts since power-up) -
You can grab those contents as your counter (usually 8 bytes worth).
Since this counter advances rapidly (GHz range today) it is unlikely
you will ever have two machines, or two serial number creations, that
strike at the same clock cycle since power-up.
(Thats a pretty small target to hit.)

Usually that will cost you one or two machine cycles to read the counter.
Relatively fast way to get "an 8 byte number I haven't used before".

Concantinate that with 8 bytes of something else of your choice that
doesn't vary with the clock cycles since power up.
If truly paranoid - 'whiten' with the hash function of your choice.
(or with AES as in another post here - many machines can do AES in hardware.)

Mike

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Peter Sylvester-3
In reply to this post by Tim Watts-2
On 05/19/2011 06:20 PM, Tim Watts wrote:

> On 19/05/11 16:46, Peter Sylvester wrote:
>>
>>
>>> The problem with this scheme is that it doesn't deal well with
>>> parallel certificate signatures. You have one shared information that
>>> must be incremented in an atomic way. But for a "Junk CA" (that's how
>>> I call the set of scripts I use), that's not a problem.
>> another approach is to take the value of 'time' (the current second)
>> and append to it the current process number, and, in case of
>> several machines, some number indicating the id of the machine.
>>
>> instead of the process number, any other method to ensure uniqueness
>> within a second may be used.
>
> Ah yes - that would guarantee a non repeating unpredictable sequence.
well, I was reminded that the number of forks may be predictable, but
one can add some random or do some random process generation, so that
you would have a large unpredictable part.
>
> I was confuse initially as I did not realise the serial number could be so big (16 bytes was it?).
160 bits, let's say 159 you would take 39 for the date, and add a few bits of local
uniqueness eg, a microsecond which is already difficult to predict,
and then you still have about 100 possible random bits.

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

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Eric S. Eberhard-2
In reply to this post by Tim Watts-2
A very simple one -- tax the time stamp register or the 4 byte cycles
since 1970, and concatenate the process id (which is unique for a
long time).  The same process id cannot get either of those two
numbers in two calls to be the same. Eric

At 10:24 AM 5/19/2011, you wrote:

>On Thu May 19 2011, Tim Watts wrote:
> > I think I might add some "randomness" into mine - seems easy enough. I
> > won't pretend I fully understand why - mostly because I wasn't clear why
> > the serial is important.
> >
>
>If your CPU has a 'time stamp register' (cycle counts since power-up) -
>You can grab those contents as your counter (usually 8 bytes worth).
>Since this counter advances rapidly (GHz range today) it is unlikely
>you will ever have two machines, or two serial number creations, that
>strike at the same clock cycle since power-up.
>(Thats a pretty small target to hit.)
>
>Usually that will cost you one or two machine cycles to read the counter.
>Relatively fast way to get "an 8 byte number I haven't used before".
>
>Concantinate that with 8 bytes of something else of your choice that
>doesn't vary with the clock cycles since power up.
>If truly paranoid - 'whiten' with the hash function of your choice.
>(or with AES as in another post here - many machines can do AES in hardware.)
>
>Mike
>
>______________________________________________________________________
>OpenSSL Project                                 http://www.openssl.org
>User Support Mailing List                    [hidden email]
>Automated List Manager                           [hidden email]


Eric S. Eberhard
(928) 567-3727          Voice
(928) 567-6122          Fax
(928) 301-7537                           Cell

Vertical Integrated Computer Systems, LLC
Metropolis Support, LLC

For Metropolis support and VICS MBA Support!!!!    http://www.vicsmba.com

Pictures of Snake in Spring

http://www.facebook.com/album.php?aid=115547&id=1409661701&l=1c375e1f49

Pictures of Camp Verde

http://www.facebook.com/album.php?aid=12771&id=1409661701&l=fc0e0a2bcf

Pictures of Land Cruiser in Sedona

http://www.facebook.com/album.php?aid=50953&id=1409661701

Pictures of Flagstaff area near our cabin

http://www.facebook.com/album.php?aid=12750&id=1409661701

Pictures of Cheryl in a Horse Show

http://www.facebook.com/album.php?aid=32484&id=1409661701


Pictures of the AZ Desert

http://www.facebook.com/album.php?aid=58827&id=1409661701

(You can see why we love this state :-) )








______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl-users] Quick eyeball requested - self generate openssl certs/CA

Eduardo Navarro
Serial Number/Randomness apart; 
 
how many certificates would you expect to issue in a year?
How would you deploy the cert for trust among the different browsers?
 
You should ensure that your certificates for SSL usage specify the appropriate EKU OID, in addition to path and issuance restrictions.
- SSL/TLS Web Server Authentication  serverAuth  1.3.6.1.5.5.7.3.1 
 
-Eduardo
 
> Date: Thu, 19 May 2011 11:28:30 -0700

> To: [hidden email]
> From: [hidden email]
> Subject: Re: [openssl-users] Quick eyeball requested - self generate openssl certs/CA
>
> A very simple one -- tax the time stamp register or the 4 byte cycles
> since 1970, and concatenate the process id (which is unique for a
> long time). The same process id cannot get either of those two
> numbers in two calls to be the same. Eric
>
> At 10:24 AM 5/19/2011, you wrote:
> >On Thu May 19 2011, Tim Watts wrote:
> > > I think I might add some "randomness" into mine - seems easy enough. I
> > > won't pretend I fully understand why - mostly because I wasn't clear why
> > > the serial is important.
> > >
> >
> >If your CPU has a 'time stamp register' (cycle counts since power-up) -
> >You can grab those contents as your counter (usually 8 bytes worth).
> >Since this counter advances rapidly (GHz range today) it is unlikely
> >you will ever have two machines, or two serial number creations, that
> >strike at the same clock cycle since power-up.
> >(Thats a pretty small target to hit.)
> >
> >Usually that will cost you one or two machine cycles to read the counter.
> >Relatively fast way to get "an 8 byte number I haven't used before".
> >
> >Concantinate that with 8 bytes of something else of your choice that
> >doesn't vary with the clock cycles since power up.
> >If truly paranoid - 'whiten' with the hash function of your choice.
> >(or with AES as in another post here - many machines can do AES in hardware.)
> >
> >Mike
> >
> >______________________________________________________________________
> >OpenSSL Project http://www.openssl.org
> >User Support Mailing List [hidden email]
> >Automated List Manager [hidden email]
>
>
> Eric S. Eberhard
> (928) 567-3727 Voice
> (928) 567-6122 Fax
> (928) 301-7537 Cell
>
> Vertical Integrated Computer Systems, LLC
> Metropolis Support, LLC
>
> For Metropolis support and VICS MBA Support!!!! http://www.vicsmba.com
>
> Pictures of Snake in Spring
>
> http://www.facebook.com/album.php?aid=115547&id=1409661701&l=1c375e1f49
>
> Pictures of Camp Verde
>
> http://www.facebook.com/album.php?aid=12771&id=1409661701&l=fc0e0a2bcf
>
> Pictures of Land Cruiser in Sedona
>
> http://www.facebook.com/album.php?aid=50953&id=1409661701
>
> Pictures of Flagstaff area near our cabin
>
> http://www.facebook.com/album.php?aid=12750&id=1409661701
>
> Pictures of Cheryl in a Horse Show
>
> http://www.facebook.com/album.php?aid=32484&id=1409661701
>
>
> Pictures of the AZ Desert
>
> http://www.facebook.com/album.php?aid=58827&id=1409661701
>
> (You can see why we love this state :-) )
>
>
>
>
>
>
>
>
> ______________________________________________________________________
> 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: Quick eyeball requested - self generate openssl certs/CA

Tim Watts-2
In reply to this post by Tim Watts-2
On 19/05/11 10:44, Tim Watts wrote:
> Hi folks,
>
> I'm setting up a new CA/SSL infrastructure for work - the CA is self
> signed and all SSL certs (mostly server certs rather than client certs)
> will be signed off against this CA.

Thanks for all your help - I've managed something that incorporates all
the corrections mentioned here, which have proven invaluable.


One further question through:

Is this the correct incantation for renewing a cert (ie resigning with a
new end date):

#revoke original
openssl ca -extensions server_cert -config blah.cnf
        -cert certs/CA.crt -keyfile certs/CA.key
        -revoke certs/www.example.com.crt

# sign a new cert from the *original* CSR

openssl ca -extensions server_cert -config blah.cnf
        -cert certs/CA.crt -keyfile certs/CA.key
        -days 1000 -in certs/www.example.com.csr
        -out certs/www.example.com.crt


 From what I understand, I only need to put the new cert on the server
in question - the corresponding key remains untouched?

TIA

Cheers,

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