@gertjan said in Renew Certificate Downstream:

I never used something like HAproxy ; but, from what I make of it, if HAproxy is doing the TLS (https) front end, unpacking the TLS an sending plain http (NON TLS) to the back end, your PBX, then yes, no certs needed on the PBX.

@johnpoz said in Renew Certificate Downstream:

This is correct, if you do the ssl offload on haproxy - you don't need any sort of ssl on the backend your sending the traffic too if your sending it has just normal http traffic.

Thank you all for the good sound of music...that's what I thought and is much better than leaving port 80 opens for Lets Encrypt on FreePBX to renew the certificate. This is just a cleaner method and basically creates a secure tunnel to the PBX.

@gertjan Well thats the thing... I used to do it that way but what I'm trying to do is to automate the new cert propagation on the network to avoid having to go manually everywhere every 90 days when acme update the certs with letsencrypt...

@gertjan thanks for the info. Needed that on another system right now.

@johnpoz I finally graduated from the University of Slow Learners after three years of repeating webGUI certificate class...wipe of sweat.

Screen Shot 2022-02-12 at 8.55.53 PM.png

Screen Shot 2022-02-12 at 8.58.37 PM.png

@gertjan Here is my thread on Let's Encrypt forum. Someone mentioned the curl POST was failing.
I have the full log posted there.

Nevermind! I had the IP address entered wrong in my RP config! It worked now!

@johnpoz OMG, I just understood what you mean 😳
Sorry, it just took me few days ...

I didn't knew we could do that, it's amazing !

Well, I will keep my first solution on that project as the person I'm working with also need to use domain from his clients which want keep managing their own zone.

But dame, I keep that for later !
Thanks a lot !

@gertjan
I was able to get it working thanks in part for your suggestion of checking the option “Enable DNS domain alias mode”.

The other part of the problem was that I typed the wrong CNAME information in my DNS provider.

I had:

_acme-challenge.cloud.MYDOMAIN.com --> MYDDNS.duckdns.org

The acme challenge Alias needs this CNAME to be

_acme-challenge.cloud.MYDOMAIN.com --> _acme-challenge.MYDDNS.duckdns.org

CNAME-corrected.jpg

After making these corrections ACME was able to issue a certificate for my domain as expected.

Thank you so much for the help.

@gertjan

Correct

So checking Firewall -> pfBlockerNG -> Alerts:
Reports: Alerts:

DNSBL Block

acme-v02.api.letsencrypt.org [ TLD ] DNSBL-HTTPS Abuse_urlhaus DNSBL_Phishing

This Feed/group is the culprit.

I'm having this error now renewing certs using ACME on GoDaddy via API keys. Anyone else having this issue?

[Thu Dec 16 15:33:20 PST 2021] Adding txt value: [REDACTED] for domain: _acme-challenge.[REDACTED] [Thu Dec 16 15:33:21 PST 2021] invalid domain [Thu Dec 16 15:33:21 PST 2021] Error add txt for domain:_acme-challenge.[REDACTED] [Thu Dec 16 15:33:21 PST 2021] Please check log file for more details: /tmp/acme/ACME-[REDACTED]-COM-CERTS-Test/acme_issuecert.log

Useful feature as Android clients no longer connect to unbound's DNS over TLS with the Letsencrypt default settings in pfSense. They will only work with Buypass certs or Letsencrypt certs with --preferred-chain 'ISRG Root X1'

@viktor_g I've added a comment to the feature request showing my interest in this. Any idea on getting this added. It really is a game changer for admins responsible for managing certs.

@gertjan
my bad! i never has see thats option!
Thanks!

@splodge said in ISRG Root X1 CA keeps re-appearing in Cert Manager when renewing in acme:

Followed the advice at https://forum.netgate.com/topic/166269/heads-up-dst-root-ca-x3-expiration-september-2021/1, deleted the old "ISRG Root X1" CA, then

.... then the expired root certifcate doesn't exist any more on your system.

@splodge said in ISRG Root X1 CA keeps re-appearing in Cert Manager when renewing in acme:

renew the certificate through acme, the expired "ISRG Root X1" CA gets re-added to the CAs list in Certificate Manager,

Your saying : it wasn't there but some one else ( = Letenscrypt ) gives you back the certificate that no one trusts ?
Really 🤤

Check this :
Locate the file
/tmp/acme/YOURACCOUNTNAMIE_IN_ACME/TOUR.DOMAINE.TLD/fullchain.cer

In this file you find 3 blocks :
-----BEGIN CERTIFICATE-----
......
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
.......
-----END CERTIFICATE-----
and root certificate :
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/
......
Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5
-----END CERTIFICATE-----

Go here : https://letsencrypt.org/certificates/ and load this file :

ac8ca021-413b-4280-a99b-932bd8e63f9b-image.png

and compare the first line and last line - ar, why not, the entire block : they are the same !!!
This root certificate is valid up until

Not After : Sep 30 18:14:03 2024 GMT

You issue is probably :
The front end that is tested doesn't use the certificate (chain) that you renewed.

@splodge said in ISRG Root X1 CA keeps re-appearing in Cert Manager when renewing in acme:

which then results in warnings from our scans.

Using a public 'scanner' (what do you mean by "scanning" ?) ?
What front-ned tool are you using ? => HA-proxy.
Check the HA-proxy settings : what certs it is using.

edit :

SSLLabs and Nessus scans showed that everything went well

Wondering if anyone has seen what I'm seeing with acme and the LetsEncrypt

Have to ask :: what are you seeing ?

@gertjan again, thanks for your ongoing help. I think I have worked out the issue.

Further reading of the log file shows that the API call that is being made is;

[Mon Nov 1 15:20:35 GMT 2021] body='<packet><customer><get-domain-list><filter/></get-domain-list></customer></packet>'

And that this call returns;

[Mon Nov 1 15:05:39 GMT 2021] The responses from the Plesk XML server were: [Mon Nov 1 15:05:39 GMT 2021] retcode=0. Literal response: [Mon Nov 1 15:05:39 GMT 2021] '<?xml version="1.0" encoding="UTF-8"?> <packet version="1.6.9.1"> <customer> <get-domain-list> <result> <status>ok</status> </result> </get-domain-list> </customer> </packet>'

Again, I am making an assumption here that this should have returned a list of domains in the result section but it isn't and that's a problem.

I then spotted that the API that's being called is a Customer related API, asking for a list of domains that a customer owns... So, I tried creating a customer (I don't use customers on this server), moved the required subscription over, changed the username and password in pfsense to the "customer" ones and we are in business.

So, to summarise. When pfsense asks for a username and password it needs to be the details for a plesk customer and the customer needs to own the subscription containing the domain you want to work with. Using and Admin account or a reseller account does not work.