Re: [PLUG] expiring certificates quickly

[brent timothy saner via plug <plug@lists.phillylinux.org>]

On 10/13/20 15:00, Rich Freeman via plug wrote:
> On Tue, Oct 13, 2020 at 2:23 PM Rita via plug
> <plug@lists.phillylinux.org> wrote:
>>
>> I am setting up postgresql ssl authentication (https://www.postgresql.org/docs/9.5/ssl-tcp.html). I have it working but I am curious if I can expire my certificates quicker.
>>
>> Here is how I request a client cert
>>
>> openssl x509 -req -in client/client.csr -days 1 \
>>         -CA certs/ca.crt -CAkey keys/ca.key -CAcreateserial \
>>         -out certs/client.crt
>>
>> Ideally, I would like to have a valid cert for 60 secs. Is possible to do?
> 
> It looks like this should be possible if you use the openssl ca app
> instead of the x509 app.  I think this requires a config file.  man
> openssl-ca has the gory details including some examples.  I don't
> think they have any end date examples, but the enddate field uses the
> format YYYYMMDDHHMMSSZ . It also supports -days.  Looking at the
> source for the x509 app days is an integer, and all the calls to
> set_cert_times just pass the days value and not explicit end dates.
> 
> The x509 app does have an option to preserve start/end dates so if you
> can generate an unsigned certificate and use that mode to modify it,
> then that might also work.
> 
> There is also a shell utility called faketime that intercepts
> date/time calls.  From what I can tell the x509 app keeps the current
> time when it sets the end date (ie if it is 1PM today and you pass
> -days 1, then you end up with a cert that expires at 1PM tomorrow).
> That means you could run it with a fake time 1 day in the past less 1
> minute, and pass -days 1, and end up with something that expires a
> minute from now.  The start date would be 1 day in the past though,
> which means that maybe it could be used for time-travel shenanigans.
> 
> I think the ca app would be the cleanest approach if you're willing to
> deal with its syntax and config files.
> 

Speaking as someone who's done CA administration via OpenSSL... I'd
recommend not. It's a PITA, especially if you want those certs' TTL to
only be 60 seconds as OP mentioned. Vault even *recommends* certificates
with extremely short expirations and is geared towards that. No need to
fake time or the like.

This is something more ideal for e.g. Vault[0], as it has a REST API[1]
that lets you automate that signing process[2]. There's definitely a
learning curve, but the realistic alternative is something like
deploying an ACME[3] server like boulder[4], which has a much more
significant learning curve. Hashicorp does have a quickstart
walkthrough[5] though, to make that learning curve a little more shallow.


[0] https://www.vaultproject.io/
[1] https://www.vaultproject.io/api-docs
[2] https://www.vaultproject.io/api-docs/secret/pki
[3] https://tools.ietf.org/html/rfc8555
    https://tools.ietf.org/html/rfc8737
[4] https://github.com/letsencrypt/boulder
[5] https://www.vaultproject.io/docs/secrets/pki#quick-start

Attachment: signature.asc
Description: OpenPGP digital signature

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug