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

Wed Sep 5 14:01:40 UTC 2018

On Wednesday, 29 August 2018 14:49:52 CEST Bear Giles wrote:
> 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.

To be honest, I don't expect it this script to take the world over. EasyRSA 
was not usable for my use case, so I created a new one, designed specifically 
for interoperability testing between different implementations. It definitely 
is not and should not be used in production environments.

If somebody wants to use it for the same use case, it will be awesome, if they 
decide to contribute to it, I'll be overjoyed. But I don't expect it to fit 
the needs of many people (hell, most interoperability testing can be performed 
with a certificate generated with a openssl one-liner:
openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt \
  -subj /CN=localhost -nodes -batch
the problem starts when you need anything more complex).

> 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

-- 
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/20180905/164ee5a2/attachment.sig>