Implement DomeneShop DNS provider

[Tarjei-stavanger]

Hi,

I'm evaluating Certify The Web for my organization.

It appears that our DNS pusher DomeneShop is not in the "DNS Update Method" drop down menu. I can see it in the list of plugins for Posh-ACME found in C:\Program Files\CertifyTheWeb\Scripts\DNS\PoshACME\Plugins.

Would it be Possible to add DomeneShop to the menu or failing that : To create a generic DNS Update Method entry which can be used to select the desired Posh-Acme plugin ?

Greetings to you all!

[webprofusion-chrisc]

Hi, Thanks for this suggestion. We don't implement every Posh-ACME provider preferring to only include ones that users ask for.

I've prepared an update you could test:
https://certifytheweb.s3.amazonaws.com/downloads/test/Certify.Shared.Extensions.zip

To try this out, extract the zip file and copy the Certify.Shared.Extensions.dll file in your existing Certify The Web installation under C:\Program Files\CertifyTheWeb which should overwrite the existing file. Then restart the certify background service and try to select the DNS provider in the app.

If you encounter problems you can revert by uninstalling the app and reinstalling the current version, this won't affect your data /settings (that's stored separately under C:\ProgramData\certify).

[Tarjei-stavanger]

I have copied the .dll to the correct directory and added apropriate credentials.
However, when I run the test I get an error message :

Powershell/PoshACME DNS :: Waiting for powershell to complete..5s
Error: No active DNS zones found for _acme-challenge-test.stavanger.kommune.no at Domeneshop at Find-DomeneshopZone, C:\Program Files\CertifyTheWeb\Scripts\DNS\PoshACME\Plugins\Domeneshop.ps1: line 296
at Add-DnsTxt, C:\Program Files\CertifyTheWeb\Scripts\DNS\PoshACME\Plugins\Domeneshop.ps1: line 24
at <ScriptBlock>, <No file>: line 33

Am I right in assuming that the credentials worked and that there might be other problems ?

[webprofusion-chrisc]

Sorry, I don't have any way to test Domenshop directly. You could perhaps try Posh-ACME instead https://poshac.me/docs/v4/ and if that works OK then the problem is in Certify The Web or your saved credentials, if it doesn't work then the problem is within the Posh-ACME provider.

[Tarjei-stavanger]

Is there any possibility of turning on logging for plugins?

I have found the logs, but I've not found any way to turn on logging for the plugins yet.

[webprofusion-chrisc]

No, we currently don't have additional logging for the Posh-ACME based plugins or any diagnostic logging in DNS plugins in general. If it errors it should log to the main log for that managed certificate but if you need to inspect http requests you'd need to install and run Fiddler or other traffic inspection software because it operates outside of our normal http logging (which is present when talking to the ACME API).

[Tarjei-stavanger]

It is a pity, because Posh-ACME when run in verbose mode tells what it is doing.

[webprofusion-chrisc]

Can you double check the saved credential is correct? The error sounds a lot like it's failing to query using your current credentials.

[Tarjei-stavanger]

The credentials are copied and pasted from Domeneshop.

[webprofusion-chrisc]

When we call posh-acme's domeneshop provider we wrap it with our own script and it looks like this:

 $PoshACMERoot = "C:\Program Files\CertifyTheWeb\Scripts\DNS\PoshACME" 
# Posh-ACME Wrapper script to allow direct use of DNS Plugins

$Public  = @( Get-ChildItem -Path $PoshACMERoot\Public\*.ps1 -ErrorAction Ignore )
$Private = @( Get-ChildItem -Path $PoshACMERoot\Private\*.ps1 -ErrorAction Ignore )

# default to TLS 1.2
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12

# Load Assembly without using Add-Type to avoid locking assembly dll
$assemblyBytes = [System.IO.File]::ReadAllBytes("$($PoshACMERoot)\..\..\..\BouncyCastle.Crypto.dll")
[System.Reflection.Assembly]::Load($assemblyBytes) | out-null

# Dot source the files (in the same manner as Posh-ACME would)
Foreach($import in @($Public + $Private))
{
    Try { . $import.fullname }
    Catch
    {
        Write-Error -Message "Failed to import function $($import.fullname): $_"
    }
}

# Replace Posh-ACME specific methods which don't apply when we're using them
function Export-PluginVar { param([Parameter(ValueFromRemainingArguments)]$DumpArgs) }
function Import-PluginVar { param([Parameter(ValueFromRemainingArguments)]$DumpArgs) }

$script:UseBasic = @{} 
if ('UseBasicParsing' -in (Get-Command Invoke-WebRequest).Parameters.Keys) {  $script:UseBasic.UseBasicParsing = $true } 
. "C:\Program Files\CertifyTheWeb\Scripts\DNS\PoshACME\Plugins\Domeneshop.ps1" 
 $PluginArgs= @{DomeneshopToken='testtoken'; DomeneshopSecret=(ConvertTo-SecureString 'testsecret' -asPlainText -force)} 
Add-DnsTxt -RecordName '_acme-challenge-test.test-domeneshop.com' -TxtValue 'WvmgGP0rElcLtiSfGPCN11_gHOu7mXzt1MQM4u5BrQI' @PluginArgs 

You could try running an adapted version of the above, replacing your dns record name and test token and secret as requires, you may need to adapt the paths to get it to run but then you could also see the verbose output.

If I try it with invalid credentials I get a (401) Unauthorized error, which is different to the issue you are seeing.

[Tarjei-stavanger]

Thanks! That looks good. I am looking into adapting Posh-ACME to provide more information from Invoke-RestMethod.

I have also asked about Posh-ACME displaying the return information from the Invoke-DomeneshopAPI function when I use the -Verbose switch.

[webprofusion-chrisc]

Great, note also that you can try this out on any machine if you have the credentials so it doesn't have to be on the server, so that may you use Fiddler to inspect the https conversation.

[Tarjei-stavanger]

If I use the latest Posh-ACME directly from Github, it will display the RestAPI data when the $DebugPreference variable is set to the right value.

I really, really, really love the debug output.

I can see that the problem is probably in Domeneshop plugin because I found the Error messag there. The answer from Domeneshop contains the requested information, so there might be an issue decoding the answer.

Fiddler is probably more complicated than just setting $DebugPreference = 'Continue'; before running the script (I like semicolons).

[Tarjei-stavanger]

The function Find-DomeneshopZone seems to be weird since it check both for stavanger.kommune.no and kommune.no. The latter have several subdomains.

I don't think the function works fine with something that returns multiple values.

I'll have a go tomorrow at finding out what the Invoke-DomeneshopAPI function really returns.