[Info-vax] Certificates
Gary Sparkes
mokuba at gmail.com
Mon Sep 11 16:12:14 EDT 2023
On Monday, July 24, 2023 at 6:49:06 PM UTC-4, terry-... at glaver.org wrote:
> On Monday, July 24, 2023 at 4:25:07 PM UTC-4, Stephen Hoffman wrote:
> > I'm not sure I see the issue for OpenVMS, as its certificate
> > implementation and integrated certificate usage is approximately zilch.
> >
> > Everybody's using their own, built atop OpenSSL.
> This was in response to a WIBNI for everything to be rewritten to use
> https:// as the sole protocol. I believe the particular usage case that
> it sprang from was LAT terminal sessions, but I might be mis-remem-
> bering.
> > As for shorter lifetimes, Google announced they were working on 13
> > months back in 2019:
> >
> > https://venafi.com/blog/jury-out-whether-reducing-certificate-lifetimes-would-improve-security/0
> >
> > I'd wager the browser vendors were encountering more certificate
> > issuance shenanigans than we will probably reasonably ever know about,
> > too. And we know about some.
> It would be nice if browser vendors showed some backbone and re-
> fused to go along with this. In that absence, it is left to the users to
> yell "Hell no, we won't go!". We see a lot of that with IPv6 and there
> is a fair amount of it behind-the-scenes which isn't visible to people
> on the outside. For example, I have 1000+ certificates signed by my
> company's bogo-root CA and that root CA installed in more browsers
> than I can count. There's also usually a "Firefox (Old SSL)" desktop
> icon on client PCs which launches Firefox 17.0.1 in a dedicated VM
> to talk to devices that only use deprecated protocols.
>From a security perspective, having seen the fallout of many compromised
certificate private keys, I want the lifetimes shorter. I've seen an in-the-wild
attack using a private key that had been compromised over a year and a
half ago on a 3-year SSL certificate that the compromise wasn't detected.
1-year expiry would have meant this attack was impossible.
But it's the browser vendors, for this reason, actually pushing the shorter
lifetimes. No one else was really pushing it hard except other security
conscious organizations.
My company's internal CA has *millions* of issued certificates. 50k+
users, 10k+ servers, network hardware of many, many vendors,
storage/SAN stuff, etc - all automated.
Manually managed/changed systems number in the 10s. And that's just
because the automation glue hasn't been written or usually because of
network pathing/relay needs. Those are being fixed (it's an internal project).
> > Discussions and actually-shorter lifetimes go back to 2015, and earlier:
> >
> > https://letsencrypt.org/2015/11/09/why-90-days.html
> That's fine for systems that have automated renewal (Certbot or
> similar). But it utterly falls flat on its face in embedded devices and
> systems that can't run Certbot. APC management cards have their
> own screwball certificate format, as do Cisco routers / switches.
> You can push new configs to (possibly hundreds of) Cisco devices
> on your corporate network every 90 days, but you had better be
> very sure that this doesn't cause other breakage (it usually does, in
> my experience). Plus, you still need to "cook" certificates into the
> screwball Cisco format so it can't really be completely automated.
Not a problem. I've automated my APC UPS cards and my cisco
devices - APs, ASAs, and IOS routers - with 90 day LE certs without
an issue. 100% automatic. 90 day lifetimes, which means frequent
private key rotation, which is *phenomenal* for security in case of
private key leakage somehow.
Hell, our Exchange environment, widespread (nationwide - all offices)
aruba AP deployment is automated. etc.
I could automate it on OpenVMS too using the automation system, it
would just SSH in and do the scripted needs.
<snip>
>One ben-
> efit of a paid-for certificate is that you could get an EV (Extended
> Validation) certificate which used to highlight the whole address
> in green to show that a site (supposedly) had Really Good Security.
<snip>
EV certificates did NOT mean anything extra about security. It ONLY
meant that the CA did additional company/identity verification of
who it was being issued to. NOTHING ELSE. It has ZERO bearing
on site security.
Essentially, EV certs became worthless over time.
All internet SSL certificates are worth is identifying the remote host
(assuming no private key compromise) and encrypting traffic
between the two. They imply or do nothing else.
> Another problem with short-lifetime certificates is when there are
> SANs for multiple domains with multiple administrative contacts.
> It was bad enough trying to herd cats for issuance approval when
> certificates lasted for 3 years. One year was impractical and 90
> days just flat-out won't work.
90 days is ridiculously easy to implement and automate with correct
validation measures - you don't need to manually approve the renewals.
My personal exchange and other public facing environments are all
on 90 day certs - even some internal stuff like my APC rackmount UPS
and APC netbotz rack system. Even my ASA I use for VPN is automated.
The only certificate I ever manually touch is my ADFS one, because of
trust renewal requirements. At work, that's also one of the above in the
'10s' list.
More information about the Info-vax
mailing list