SCIENTIFIC-LINUX-USERS Archives

July 2016

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steven Haigh <[log in to unmask]>
Reply To:
Steven Haigh <[log in to unmask]>
Date:
Thu, 14 Jul 2016 23:44:42 +1000
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (2664 bytes) , signature.asc (834 bytes)
On 14/07/2016 11:24 PM, Steven Miano wrote:
> If you are automating the process, it has no impact on your environment,
> maintenance, or administrative costs.
> 
> The only reason I could see a short lifespan of the certificates being
> an issue is if you were manually caring and feeding them. 
> 
> From LE:
> 
> "At launch all certificates will have a lifetime of exactly 90 days.
> Post launch we will possibly offer more options, but they will likely be
> on the shorter side rather than the longer side. Part of the rationale
> for the 90 day number is that when certs are renewed only once a year, a
> lot can change. The person in charge might forget how to do it, or leave
> the organization, or change email addresses, etc. A shorter lifetime
> will hopefully encourage people to automate the renewal process, and
> we'll provide tools to help with that."

I hadn't actually read that previously, but it seems about as badly
thought out as having to run some magic script every 88 days that nobody
knows how to fix it etc etc.

The reasons give above for having a short expiry time "someone might
forget how to do it"? Really? Are you kidding me?

Anyway, rubbish reasons like that aside, the expected hands-off
automation of something like SSL certs imho leaves the mentality of 'set
and forget' for the server. That is bad. Real world experience shows
that this causes other problems.

In fact, one system I inherited was a 'set and forget' system that ran
perfectly. That perfectly that nobody realised that the security updates
went EOL for that system back in 2009. It was only discovered by me when
something misbehaved 7 years later.

So yes, I understand the mentality - but it is based on false reasoning.
Nearly 20 years in this area has taught me the practical way on these.

So, the best method I've seen? Set a reminder in your calendar for 7
days before your cert expires, and renew away. StartSSL will even send
you nice reminders that your cert is about to expire. What a great way
to not forget a system :)

I wrote that StartAPI system to make my life easier. I admin somewhere
in the order of 40 systems including production, staging, development
environments on those systems. I'm working on a deploy script to assist
- but the key part is that the certificates and management are all
centralised - not on each individual system.

Total time to renew a cert, about 5 minutes per year - and I know
exactly where I have them - and whoever gets to take over after me will
get the email reminders for each system as they come due.

Of course, if you only run one server..........

-- 
Steven Haigh

Email: [log in to unmask]
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



ATOM RSS1 RSS2