Save credentials for Custom Script

Is there any future plans to allow for saving “Custom Scripts” APIs. Currently, I have to save API in the plain text file on the C Drive.
It would nice to add another arguments into the bat script that would pass it off to the in my case power shell script.

Hi, not currently but it’s an interesting idea. In the future we will also be looking at integrations for things like Azure Key Vault and Hashicorp Vault, which are probably the best long term solution (storing secrets off the machine altogether, with an audit trail for accesses).

In the meantime you could possibly use the windows file encryption to achieve much the same effect as the Certify credentials store, your file needs to be readable by Local System.

Hi,
I’m not seeing support for the ability to store API credentials for Custom Scripts. I don’t see it in version 5. Is it so something you’re thinking about adding in to Certify the Web?

1 Like

Thanks, it’s not a feature in v5 yet but I do think it’s worth adding. I think to do it properly we need to provide a way to add a set of credentials as named arguments to pass to powershell as either strings or securestrings. I’d also like use to be able to pull from different credential vaults (other than the certify one) - that’s quite a big chunk of work though and currently it’s just all about stabilizing v5.

As a workaround you could (I think) use Certify v5, run deployment task as a specific user, and use Powershell Secrets as a store, your script would then take care of fetching the credentials itself.

1 Like

So I’m trying to make the API keys encrypted into the system so that way they’re not in plain text. However for some reason even though it gets loaded into memory. ( you can see it in plain text) however, the invoke rest method is not liking the API keys. Is there another or better way of doing this? ( I have already changed the API keys for security reasons.)

PS C:\WINDOWS\system32> $TXTAdder = "C:\TXTAdder\"
PS C:\WINDOWS\system32> $APIKey = Get-Content  -Path "$TXTAdder\DynuAPIKey.txt" | ConvertTo-SecureString
PS C:\WINDOWS\system32> $getdomaindata = Invoke-RestMethod -Method GET -Uri `https://api.dynu.com/v2/dns/' -ContentType `application/json' -Headers @{ "Api-Key" = $APIKey }
Invoke-RestMethod : {"statusCode":401,"type":"Authentication Exception","message":"Failed."}
At line:1 char:18
+ ... omaindata = Invoke-RestMethod -Method GET -Uri ‘https://api.dynu.com/ ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand
PS C:\WINDOWS\system32> [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR((($APIKey))))
5W64fUYe66UUfTWg67bfU64ebg63W6fd
PS C:\WINDOWS\system32>

Currently you are reading APIKey and making it a secure encrypted string (in memory), then you try to use it while it’s still encrypted, which doesn’t work.

You would want to write out your secret as an encrypted value, so it’s encrypted on disk. Then I think you would want to ConvertFrom-SecureString when reading that from disk. Then you should have the unencrypted value in memory and echo $APIKey should show your unencrypted key in the output.

Also, when using encryption on windows, the process doing the encryption/decryption needs to be the same user, so if this is for DNS validation you’d be running as Local System, therefore you need to create your encrypted credential file as Local System (not your normal admin user). I use psexec to open a command prompt as local system: windows services - How do you run CMD.exe under the Local System Account? - Stack Overflow

You may also need to set the http header to API-Key if that header is case sensitive (it probably isn’t)

Has there been any development on allowing save credentials to be passed to Powershell?

Sorry no, this feature hasn’t been worked on yet. The long term debate is whether Certify should really be the source of secrets or whether you should use an established organisation secrets vault like Azure Key Vault or Hashicorp Vault instead. For other vaults that would all be something you did in your script anyway.

Long term we would also like to be able to pull specific secrets from these vaults instead of storing them. While our secrets storage is protected by local DAPI it lacks distribution, so you can end up having to store the same secret on each machine, which isn’t ideal.