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

[Bear Giles]

This is a total aside but I prototyped a PostgreSQL extension that
implemented the PKI infrastructure using OpenSSL. (The OpenSSL C API...
shudder.) The database server already had it present, for SSL support, so I
could piggyback on that and not worry about export restrictions since
anyone that couldn't use OpenSSL couldn't run my extension either.

It was a hobby project and I largely dropped it for various reasons. Some
of it was specific to PostgreSQL (migrating away from OpenSSL) but a lot of
it was because there was already enough "good enough" solutions that the
perceived need had gone away. Many open source projects had documentation
for EasyRSA, but now they have integrated support for LetsEncrypt.

Anyway the point is that these type of projects have to be careful that
they don't invent a better mousetrap in a world where nobody is looking for
one. It's a fun project where you can learn a lot but it won't get much
traction unless it's a totally new approach. The existing solutions may
have flaws but most of the places where you need a CA already have
documentation on how to use EasyRSA, if not outright integration with a
solution.


On Mon, Aug 27, 2018 at 4:18 PM Hubert Kario <hkario at redhat.com> wrote:

> 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--
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180829/0a35f323/attachment.html>