[openssl-users] Wrapper script for creating PKI with openssl Was: OpenSSL version 1.1.1 pre release 9 published

[Hubert Kario]

Changing Subject to help googlability :)

On Monday, 27 August 2018 22:38:24 CEST Robert Moskowitz wrote:
> On 08/27/2018 04:07 PM, Hubert Kario wrote:
> > now, for generating testing certificates (and what's more important, the
> > whole PKI) we are using this script to provide sensible defaults and easy
> > way to generate certificates with just few options departing from those
> > defaults: https://github.com/redhat-qe-security/certgen
> 
> I will take a look at this.  It did not come up in my google searches a
> year ago.  Guess just not asking the right question or github is
> protected from google...

definitely isn't; most of the visits on my other repos come from google (if 
github stats are to be believed)

likely because similar scripts are not uncommon (e.g. OpenVPN ships with 
something similar) and this one is hardly well known, so it got delegated to 
"2nd page"

> > to get a PKI you run those commands:
> > source certgen/lib.sh
> > x509KeyGen ca
> > x509KeyGen server
> > x509SelfSign ca
> > x509CertSign --CA ca server
> > 
> > The private key file will be printed by use of:
> > x509Key server
> > to get certificate file name you run:
> > x509Cert server
> 
> In testing situations I have been in, intermediate CAs, revocation, the
> like are needed.

it allows you to create arbitrarily complex CA structure, this is just the 
simplest example; there is also support for generating client certificates, 
OCSP reponder certificates, subject alternative names, etc.

to get an intermediate you have to run the following commands:
x509KeyGen subca
x509CertSign --CA ca -t CA subca"

the you can use 'subca' instead of 'ca' for signing the server cert:
x509CertSign --CA subca server

(the -t of 'webserver' is simply the default)

revocation is not implemented yet, but as the tool keeps all the information 
about CA's signed certificates (it does use internally the `openssl ca` tool), 
adding it shouldn't be too hard... (and you can always do it manually)

> Plus getting more interest in 802.1AR certs with vendors (can't get
> certs to test out my product design).

that I'm not familiar with

> > (easy switches are also provided to get DER files or PKCS#12 files instead
> > of the default PEM format)
> 
> I will be interested to see how you handle DER, as I found cases where
> the command line was broken.  Read my caveat section.  In some cases you
> have to make the file in PEM then convert to DER.  Plus there is no DER
> way to handle cert chains as was discussed here a year ago.  So I will
> be interested to see how you handle cert chains non-PEM.

The scripts internally keep everything as PEM files; DER, PKCS#12, etc. are 
for export only.

If you want cert chains you have to create them manually. As I started to work 
on this script for the CA cross-signing, the built-in assumption was that 
there is no One True Cert Chain™. So it considers all CAs as stand-alone. If 
you want a cert chain you have to assemble it yourself.

> > to get ecdsa certificate, you just need to change one of the above lines
> > with x509KeyGen to have `-t ecdsa` specified. Want RSA-PSS certificate? do
> > `-t rsa-pss`.
> > 
> > See runtest.sh for other examples.
> 
> I will take a look.

Limited time offer! Call now and get Ed25519 support completely free! ;)
https://github.com/redhat-qe-security/certgen/commit/
4b71e0a7d77929d944cc20f16f2ccf9514d6d94d
 
> > It is compatible with all versions of openssl since RHEL-4 (so 0.9.7), if
> > a
> > given feature is supported in that version of openssl.
> > 
> > (while ed25519 support is not yet there, it will be in few weeks, I was
> > running just basic tests of it, without involving full PKI)
> 
> Nice.  See https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki
> 
> I am right now adding an algorithm variable to support ed488.
> 
> This actually does not work right with 1.1.1-pre9, as PR 6901 did not
> make that build, so I have to do my command and .cnf patches still.

yes, there are quite a few warts you need to worry about when working with 
different versions of OpenSSL, then there is the problem of updating it as 
recommended key sizes or hashes change...

reading that draft feels like reading a heavily commented script – not a 
criticism, rather observation about the problem at hand

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180828/0739d372/attachment.sig>