@Gertjan I confirmed that the last solution works for me too (unbound, Restart Local Service).

@Risfold said in DoH Verification Method:

I have just started having the same issue, and came across this thread in researching it. I hope to revive the discussion. I also use the above referenced DoT/DoH blocking list. I block the the domains and IPs via pfblocker for LAN clients to stop any circumvention of DNS or hard coded DNS in clients. I alternatively use DoT from unbound in pfsense.

The acme.sh discussion of this addition appears to be here, added mid-February 2020. It is discussed as "support" for DoH, but it appears to be implemented more as a change rather than an option.

I fully support the addition of DoH in acme.sh, even as a default, but is there a way to turn off the use of acme.sh's use of DoH, and return to using the firewall for DNS? I could temporarily disable my blocking of DoH but that would defeat the purpose of automated certificates.

Work around noted here.

add dnssleep time of 180

Logs ?

Open a console, SSH, or better SFTP and look in /tmp/acme/your-domain.tld - there is a dot log file.
This one :
112f5526-6111-4ba0-ad23-9802642eac83-image.png

Also :

If I visit :
2ea7a531-3b5f-4933-9840-3c6459963808-image.png

I have a TLS error - as acme has :

d44fcbf1-8c98-4ae5-a1e8-5114913e991d-image.png

because the cert is expired since March 6.

So, when the Letenscypt hits that site, it will bail out.

I'm not using HAProxy myself, neither the acme webroot method.

What about : pfsense haproxy acme ,

@Blfrg Thanks, that worked perfectly. Your last fix also works with the GUI of PFSense when added from hand. After merge all should be fine again. Thanks for your patch!

@Wasca Thank you for reporting the issue!

A pull request has been created here

Please watch for that pull request to be merged
and the fix should be available in the next acme.sh release (>2.8.6)

Also noteworthy that I am still occasionally seeing account registration/verification failures over IPv6 even when attempting renewals. If you get a cURL error (like error 35) when attempting to renew, set the firewall to prefer IPv4: System > Advanced, Networking tab, check Prefer to use IPv4 even if IPv6 is available. Then try the ACME renew again.

The resulat (green text) said already to you :

d643c3b0-666f-4b89-b9a5-843a3984ed7a-image.png

But this could be an important indication :

bc053a13-aa12-496d-92a6-bf53421a2632-image.png

Let me rephrase that message : the acme.sh couldn't add the "_acme-challenge.............." to your domain.
A problem with the domain ? An API error ? The registrar that hosts the API has problems ?
Can't tell much more.

@PiBa I use the 'simple' haproxy package. I am not blocking anything special. pfSense and all packages are on newest versions. I also disabled snort, pfblocker and everything else during debugging. As i said, it worked before moving from bhyve to proxmox. Or probably what counts more is before backup up and restoring on a clean install.

But nevermind, i got it working now by using the haproxy chroot'ed webroot instead of standalone http server. After hours or fiddeling i have up on the other solution and switched all my certs to webroot. This is even faster as the script does not have to spin up an extra http server ...

But thank you for taking the time to reply ;-)

I would not consider TFTP safe by any means. It's unencrypted and unauthenticated. So you can't verify that the client is pulling the certificate from the proper source or ensure that it has not been interfered with along the way. On a local network that may not appear like a huge concern, but it's best not to get complacent or make assumptions when dealing with security.

If you are only transferring the certificate and not private key data then the unencrypted part isn't as large of a concern.

Some people write the certs to a central location and copy them around with scp, which is better.

Though it sounds like you're using the ACME package for a role it really was not intended to fill. You might be better suited using a dedicated ACME setup on a local system (small VM, Pi, etc) which can securely deploy the certificates in a manner better suited for your needs.

Before posting :

7f2dd95b-5c4d-4013-820c-42ca9263efa6-image.png

Right after manual cert renewal :

86f8b0a5-1058-43d1-844a-2c70ee1ac91c-image.png

You saw the date/time change ?

The concerned

<cert> .... <crt> ........</crt> ..... </cert>

in the config.xml showed me the cert was changed thus saved to config.xml

How could pfSense otherwise use the new certificate dater a reboot ?
Because it's in the config.xml .... (and no where else).

Btw :

a397d082-d42c-478b-b7fc-0eae9ab12b7b-image.png

edit : I tend to say : read the log from /tmp/acme/<your domain>/acme_issuecert.log and you have your answer why it was not renewed and thus why it wasn't written to config.xml and why it didn't doesn't show in System > Certificate Manager > Certificates

Edit : See the official video : https://www.netgate.com/resources/videos/lets-encrypt-on-pfsense.html => 49 minutes and 30 seconds ;)

It is fixed: https://github.com/acmesh-official/acme.sh/commit/4f303de00c8d640351db5fb065bf0861786fab18

We need to wait for offical release (2.8.6).

Or you can copy acme.sh from master branch it will work as well.

It will still be valid until the old certificate expires, which thanks to ACME's short life, will only be 90 days from the date it was issued. No need to go through the hassle of revoking.

Looks like the error is being sent back from api.dnsmadeeasy.com -- so I'd check your account settings there and the credentials. Maybe they have some limit you're exceeding, or something else wrong.

One of these should work:

Method = Restart Local Service, Command = ipsec (This may be enough to refresh the IPsec config, but it's not a full restart) Method = PHP Command, Command = ipsec_configure(true) (This may fail since it may not have the right required libraries) Method = Shell Command, Command = /usr/local/sbin/pfSsh.php playback restartipsec (This may fail since the ACME script which starts the command is PHP, and launching pfSsh.php from within PHP doesn't always work) Method = PHP Command, Command = file_get_contents("/etc/phpshellsessions/restartipsec") (If the shell command fails, this should work instead)

@Gertjan said in acme when dns provider does not allow dns challenge:

I see how speed may become an issue here.

set DNS-Sleep to 300 seconds, or more.

I'll certainly remember that setting when needed.

I read here in the forum that someone had a similar problem and it suddenly solved itself without intervention.

Here the same.

PFSense was running all the time and I tried again yesterday to create the account key which didn't work as described. The system wasn't changed all the time because I think the settings are correct.

I have just tried it again and see there it is created.

So (probably) done but strange I find it already.

Hi,

And how should we know what changed, went wrong - what method you are using, etc ?

Update: When I try to setup Dynmaic DNS RFC 2136 updates (just to test) I noticed this error:

/services_rfc2136_edit.php: The command '/usr/local/bin/nsupdate -k /var/etc/nsupdatekey0 /var/etc/nsupdatecmds0' returned exit code '1', the output was 'check-names failed: bad owner '_acme-challenge.<doamin.com>' syntax error'

I briefly looked up solutions but then mentioned puny-code and I still don't quite understand. Going to keep looking into this.