On 2023-07-24, terry-...@glaver.org <terry-groups@glaver.org> wrote:
>
> We can't forget that certificate lifetimes have become shorter and
> shorter - you can't buy a SSL certificate with a longer expiration date
> than 1 year + any time remaining on the existing certificate. I think the
> only reason they haven't shortened it further is that once they get it
> down to 180 days, there's pretty much no reason not to use Lets
> Encrypt unless you're a bank or similar institution. I think the SSL
> certificate vendors would complain that their customer base would
> leave if they did that.
>

You can blame Apple for that piece of utterly moronic stupidity:

https://www.theregister.com/2020/02/20/apple_shorter_cert_lifetime/

and then Google followed:

https://www.theregister.com/2020/06/30/tls_cert_lifespan/

I have also just discovered this piece of utter insanity which I didn't
know about until a few minutes ago:

https://www.sectigo.com/resource-library/google-announces-intentions-to-limit-tls-certificates-to-90-days-why-automated-clm-is-crucial

Complete and utter insanity. What the hell makes Google think they
have the right to do this??? :-(

You were way too optimistic when you said 180 days above.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-07-24 17:37:37 +0000, Simon Clubley said:

> On 2023-07-24, terry-...@glaver.org <terry-groups@glaver.org> wrote:
>>
>> We can't forget that certificate lifetimes have become shorter and
>> shorter - you can't buy a SSL certificate with a longer expiration date
>> than 1 year + any time remaining on the existing certificate. I think the
>> only reason they haven't shortened it further is that once they get it
>> down to 180 days, there's pretty much no reason not to use Lets
>> Encrypt unless you're a bank or similar institution. I think the SSL
>> certificate vendors would complain that their customer base would
>> leave if they did that.
>>
>
> You can blame Apple for that piece of utterly moronic stupidity:
>
> https://www.theregister.com/2020/02/20/apple_shorter_cert_lifetime/
>
> and then Google followed:
>
> https://www.theregister.com/2020/06/30/tls_cert_lifespan/
>
> I have also just discovered this piece of utter insanity which I didn't
> know about until a few minutes ago:
>
> https://www.sectigo.com/resource-library/google-announces-intentions-to-limit-tls-certificates-to-90-days-why-automated-clm-is-crucial
>
>
> Complete and utter insanity. What the hell makes Google think they
> have the right to do this??? :-(
>
> You were way too optimistic when you said 180 days above.

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.

Using the ACME tooling (RFC 8555) will probably involve a second box
and transfers, though—ACME hasn't been ported to OpenVMS AFAIK.

Automation helps. OpenVMS is lacking there, though.

https://ivision.com/blog/why-shorter-ssl-certificate-lifetimes/

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.

A whole lot of effort went into weakening TLSv1.3 as part of efforts
toward easing TLS interception too, though most of those efforts seem
to have failed in the final standard.

Discussions and actually-shorter lifetimes go back to 2015, and earlier:

https://letsencrypt.org/2015/11/09/why-90-days.html

DEC/Compaq/HP/HPE does have one long-lived certificate that'll blow up
with the first signed product kit installs after 31-Dec-2028, though.

--
Pure Personal Opinion | HoffmanLabs LLC

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.

> 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.

If the rest of the certificate vendors get forced into issuing only
90-day certificates, there is absolutely no reason for most cus-
tomers to pay for certificates if they can get one for free. 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.
Then browsers changed to just showing the padlock icon in green,
and recently started not indicating an EV certificate at all because
it "confuses users".

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.

On 7/24/2023 1:37 PM, Simon Clubley wrote:
> On 2023-07-24, terry-...@glaver.org <terry-groups@glaver.org> wrote:
>> We can't forget that certificate lifetimes have become shorter and
>> shorter - you can't buy a SSL certificate with a longer expiration date
>> than 1 year + any time remaining on the existing certificate. I think the
>> only reason they haven't shortened it further is that once they get it
>> down to 180 days, there's pretty much no reason not to use Lets
>> Encrypt unless you're a bank or similar institution. I think the SSL
>> certificate vendors would complain that their customer base would
>> leave if they did that.
>>
>
> You can blame Apple for that piece of utterly moronic stupidity:
>
> https://www.theregister.com/2020/02/20/apple_shorter_cert_lifetime/
>
> and then Google followed:
>
> https://www.theregister.com/2020/06/30/tls_cert_lifespan/
>
> I have also just discovered this piece of utter insanity which I didn't
> know about until a few minutes ago:
>
> https://www.sectigo.com/resource-library/google-announces-intentions-to-limit-tls-certificates-to-90-days-why-automated-clm-is-crucial
>
> Complete and utter insanity. What the hell makes Google think they
> have the right to do this??? :-(
>
> You were way too optimistic when you said 180 days above.

Apple, Google and Mozilla decide what certificates their
browsers will accept.

Everybody can write a browser with a different policy. But
most likely web sites and certificate issuers will want
to support the 99.9% that use a browser from those 3.

I believe the primary reason for doing this is to
ensure that the web site is indeed owned by those
that the certificate was issued to.

And secondarily to get rid of certificates based
on obsolete algorithms.

That damn security again!!

I am not convinced that the first argument is good. If the web site
is important then something should be done in hours/days. If the web
site is not important who cares. What web sites has a severity level
where being faked for 1/3/6/12 months is OK but being fakes for 3/5/10
years is a problem.

Arne

On 7/24/2023 7:25 PM, Arne Vajhøj wrote:
> On 7/24/2023 1:37 PM, Simon Clubley wrote:
>> On 2023-07-24, terry-...@glaver.org <terry-groups@glaver.org> wrote:
>>> We can't forget that certificate lifetimes have become shorter and
>>> shorter - you can't buy a SSL certificate with a longer expiration date
>>> than 1 year + any time remaining on the existing certificate. I think the
>>> only reason they haven't shortened it further is that once they get it
>>> down to 180 days, there's pretty much no reason not to use Lets
>>> Encrypt unless you're a bank or similar institution. I think the SSL
>>> certificate vendors would complain that their customer base would
>>> leave if they did that.
>>>
>>
>> You can blame Apple for that piece of utterly moronic stupidity:
>>
>> https://www.theregister.com/2020/02/20/apple_shorter_cert_lifetime/
>>
>> and then Google followed:
>>
>> https://www.theregister.com/2020/06/30/tls_cert_lifespan/
>>
>> I have also just discovered this piece of utter insanity which I didn't
>> know about until a few minutes ago:
>>
>> https://www.sectigo.com/resource-library/google-announces-intentions-to-limit-tls-certificates-to-90-days-why-automated-clm-is-crucial
>>
>>
>> Complete and utter insanity. What the hell makes Google think they
>> have the right to do this??? :-(
>>
>> You were way too optimistic when you said 180 days above.
>
> Apple, Google and Mozilla decide what certificates their
> browsers will accept.
>
> Everybody can write a browser with a different policy. But
> most likely web sites and certificate issuers will want
> to support the 99.9% that use a browser from those 3.
>
> I believe the primary reason for doing this is to
> ensure that the web site is indeed owned by those
> that the certificate was issued to.
>
> And secondarily to get rid of certificates based
> on obsolete algorithms.
>
> That damn security again!!
>
> I am not convinced that the first argument is good. If the web site
> is important then something should be done in hours/days. If the web
> site is not important who cares. What web sites has a severity level
> where being faked for 1/3/6/12 months is OK but being fakes for 3/5/10
> years is a problem.
>
> Arne
>
>

Well the problem is, what do people pay for a browser? Usually nothing. So one
gets what one pays for, and, what leverage is there on browser vendors?

Ever get told you cannot access a web site because they don't have adequate
security? To then wail "but I need what they have". It really gets me upset.
But I'm too lazy to write a browser.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2023-07-24, terry-...@glaver.org <terry-groups@glaver.org> wrote:
>
> Then browsers changed to just showing the padlock icon in green,
> and recently started not indicating an EV certificate at all because
> it "confuses users".
>

I strongly suspect that is more about some UI designer wanting to set
a fashion (so they can list it on their CV) and to hell with the users. :-(

It's the same kind of mindset that gave us those idiotic 1px borders
in Windows 10 (although at least in Windows 10, there's a way to get back
normal width borders if you can live with a somewhat naff colour scheme).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Monday, July 24, 2023 at 6:49:06 PM UTC-4, terry-...@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.

On Monday, July 24, 2023 at 4:48:58 PM UTC-7, Dave Froble wrote:

(snip)

> Ever get told you cannot access a web site because they don't have adequate
> security? To then wail "but I need what they have". It really gets me upset.
> But I'm too lazy to write a browser.
I have a Sun server in the basement that has ILO management.

Trying to log into it, and it told me that I should contact the owner.
Well, the owner is me, so that didn't help any.

The server is in firmware, and I don't have an upgrade contract.

There are complicated ways to tell the browser to ignore the problem,
and only for some browsers.

On Monday, September 11, 2023 at 1:12:17 PM UTC-7, Gary Sparkes wrote:

(snip)

> 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.

They are needed to avoid "man in the middle" attacks.

Especially on public WiFi nets, or even more, pretend public WiFi nets,
someone can pretend to be your back, and run an https server.
Then you connect to that server, which then decodes the message,
is it supplied the key. Then it contacts your bank, and has it do what
you actually asked for.

I am not quite sure how good they are at doing that by now.
Best not to access your bank from public WiFi nets.

On Monday, September 11, 2023 at 4:50:57 PM UTC-4, gah4 wrote:
> On Monday, September 11, 2023 at 1:12:17 PM UTC-7, Gary Sparkes wrote:
>
> (snip)
> > 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.
> They are needed to avoid "man in the middle" attacks.
>

That's precisely the point I was trying to make - that's all they're good for.

Identify the machine - "Is this the host I want to connect to?"

Encrypt the traffic between you and the machine -
"I know who i'm talking to now, and no one can read this and we
can detect if it's been modified(invalid data)/intercepted
(certificate changes)"