NetTalk Central

Author Topic: Attacked by Let's Encrypt  (Read 2826 times)

Jane

  • Sr. Member
  • ****
  • Posts: 371
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Attacked by Let's Encrypt
« on: July 19, 2023, 03:17:49 PM »
At least I *think* it's ACME gone rogue.

I have an API/web server on an internal LAN.  It's been using a certificate from our local certificate authority that's trusted by Active Directory.

That certificate expires on August 19.

It appears that yesterday the ACME service helpfully decided that my certificate was too stale for its taste.  Couldn't get something from Let's Encrypt (since I'm on a LAN).  And decided to overwrite my still-good certificate with its own new rubbish certificate issued by sales@capesoft.com.
Well, it may be rubbish but at least it's good for a year!

Is there some way to pull the teeth on this?  I don't want to replace the legitimate cert until the beginning of August but don't want the server overwriting it each night.

TIA

Jane

Jane

  • Sr. Member
  • ****
  • Posts: 371
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Re: Attacked by Let's Encrypt
« Reply #1 on: July 19, 2023, 06:44:14 PM »
I had had the word "something" in the CA Account entry field on the web server.

I've blanked that field to see whether that will inhibit the automatic cert-fetching.

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11245
    • View Profile
Re: Attacked by Let's Encrypt
« Reply #2 on: July 19, 2023, 11:19:28 PM »
Morning Jane,

ok, so to be clear here, this has nothing to do with LetsEncrypt.

The NetAcme class in NetTalk has the job of looking after your certificates - both the public ones (which it uses an online service, like LetsEncrypt), AND the local ones (which uses OpenSSL.) When a certificate is "nearing expiry" it will automatically attempt to replace it. This is true for local intranet, and internet ones.

As you note, your cert expires on 19 august, so we are now in the 30 day window for renewal. Which is what happened - it generated a new local cert for you (wasn't that helpful!) :)

So to clarigy the cause

>> It appears that yesterday [NetTalk] helpfully decided that my certificate was too stale for its taste.

I'm stressing this point here because I don't want there to be any FUD about the LetsEncrypt service, or its certificates. LE was not in play here, NetTalk was.

The time boundary is an equate in netacme.inc
CERTEXPDAYS              Equate(33)
so one approach is to make this equate smaller.

I _think_ removing the CA Account field will also inhibit it. Without this field it can't create certificates either way. (I guess you'll let me know later today.)

Cheers
Bruce


Jane

  • Sr. Member
  • ****
  • Posts: 371
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Re: Attacked by Let's Encrypt
« Reply #3 on: July 20, 2023, 11:36:58 AM »
What?  Me?  FUD??  Pshaw!

In fairness, my hyperbolic clickbait post headline was followed up by a more specific reference to ACME rather than to Let's Encrypt itself ;)

Clearing the CA field seems to have inhibited its compulsion to "help" me with a new certificate.
It's running as a service so I can't see whether it put anything in the log about doing a certificate check.
Good to know about the equate in the inc file but I don't want to rebuild the app just to change that unless I have to.

Anyway, people not using Let's Encrypt might want to be aware of this possibility.

With all due respect to Let's Encrypt, which I'm hoping to use with the new ACME magic promised for NT 14.

FUDD?