Insecure Redirect error when attempting to create DNS-01 records with DNS Made Easy

Question
1

Hello, first off - I did search through the forums for DMEasy.ps1, insecureredirect and Posh-ACME with only the last phrase coming back with any results but nothing seemingly relevant.

This is my first time attempting DNS-01 authentication, as we usually use HTTP-01, but for this domain, we have control over DNS.

In our configuration, we have a separate task which writes out the leaf/chain/key. We are not writing directly to IIS. We are simply using CCM to interface with LE and we handle the certificates via separate powershell tasks afterwards. Just putting this out there, to help frame the issue better.

I am getting errors when I’m attempting to create the certificates. The errors pertain to the DMEasy.ps1 file when interfacing with the DME POSH API.

Here is one of the messages (this certificate is requesting a SAN with three related FQDNs)

2026-08-16 14:15:08.790 -05:00 [ERR] DNS update failed: DNS Made Easy DNS API (using Posh-ACME) :: PowerShell Execution Mode: InProcess.
PowerShell Host: Core 7.6.3
Error: Cannot follow an insecure redirection by default. Reissue the command specifying the -AllowInsecureRedirect switch. at Add-DnsTxt, C:\Program Files\CertifyTheWeb\Service\Scripts\DNS\PoshACME\Plugins\DMEasy.ps1: line 62
at , : line 42

I see in the DME audit logs the three records being created and then deleted, so I’m a little confused as to the true nature of the error. Although the second time around, it apparently wasn’t able to delete the records automagically. But both the first and second attempts came back with the same failure message.

Doing a little bit of googling, I found that PowerShell 7.4 and greater added the -AllowInsecureRedirect, presumably because Invoke-RestMethod no longer follows insecure redirects, as the error message states.

As you can see in the error message, this machine is on 7.6.3. The last LTS version that apparently supports insecure redirects, 7.2, went end-of-support nearly two years ago.

Looking at the DMEasy.ps1, I don’t find any strings matching “http:”, only “https:”. While I haven’t loaded up wireshark and configured this system to snag the SSL keys, would the http redirects come from DME directly?

So - all that said, what is the best way to resolve this problem?

Thank you for your time.

2

Interesting updates -

  1. Looking into the Advanced/Details section of CCM, I actually see the three FQDN test certificate in there - it seems that whatever that PowerShell error is/was, was not fatal to the process. This makes sense given that I saw in the DME audit trail that the DNS records were ultimately created and deleted.

  2. Having thought further about having multiple FQDNs on a single certificate and some of the possible problems I might have as I automate this (we use Netscalers as our front-end - so everything is custom coded), I created a single identifier certificate in CCM and the test certificate with LE was created with no PowerShell errors. I don’t understand the relevance here.

3

Another update - I think I know why the PowerShell error disappeared on the reattempt - the authorization for the earlier multi-FQDN SAN certificate was still valid. The CCM log indicates the following:

2026-08-16 17:25:53.613 -05:00 [INF] Order is ready and valid. Auth challenges will not be re-attempted.

Presumably this following LE’s stated guidance that authorizations are valid for 30(??) days currently.

The reason I looked for this is that when I flipped from Testing/Staging CA to their production, I encountered the exact same failure message as listed in the original post - presumably the authorization does not carry between Staging and Production. This makes sense to me.

4

Hi, thanks for your feedback. Yes this is a known issue and for DNS Made Easy specifically we will add the Allow Insecure Redirect in the next update - the change has already been made we’re just waiting on the update being published.

This is a weird bug in the DNS Made Easy system (an https to http redirect, or vice-versa) and is not something related to our code, as far as we’re aware.