We have some Runbooks executing on our Deploy Server that are using Lets Encrypt to create Certificates and then install into the Octopus Certificate store.
Up until recently these run books were working fine and now we have noticed them failing.
On checking we found a couple of issues most of which have been resolved for the most part, but the most problematic has been once we have received the generated Certificates from Lets Encrypt.
Once we have received the certificates we are using the response from Posh-Acme’s New-PACertificate. The result of this call contains a list of paths to the certificates that have been created and stored in Posh-Acme’s temp store.
We then take a path for the FullChain PFX file and attempt to read it into a Byte Arrays using ReadAllBytes but keep getting an error that the file name is in an invalid format
NotSpecified: Exception calling "ReadAllBytes" with "1" argument(s): "The filename, directory name, or volume label syntax is incorrect. : 'E:\Octopus Deploy\Octopus Home\Work\20220118034235-29973-368\ C:\Users\svc_deploy\AppData\Local\Posh-ACME\acme-staging-v02.api.letsencrypt.org\<nnnnnnn>\!.subdomain.domain.com\fullchain.pfx'"
January 18th 2022 14:45:17Error
At E:\Octopus Deploy\Octopus Home\Work\20220118034235-29973-368\Script.ps1:253 char:5
January 18th 2022 14:45:17Error
+ [Byte[]]$certificate_buffer = [System.IO.File]::ReadAllBytes($Cer .
January 18th 2022 14:45:17Error
It can be seen that the file name can be read but it is now failing
I would have to do some testing, but to me the issue could be the the literal string tokens around the Work Directory and fully qualified Certificate path. i.e. ReadAllBytes is expecting the one path, however the Octopus Working directory and the fully qualified certificate path are being evaluated into the one argument - which makes the path invalid.
There may need to be an extra line or two or some escape characters required in the step template to properly present the PFX file to LetsEncrypt. Would you be able to provide the relevant lines of code in the runbook?
Feel free to redact any information you don’t want to share.
Have found out the issue. The issues encountered appear to be related to the version of Powershell being used.
Personally I am new to the organization, so not sure if this job was reconfigured at some point, but prior to this month the RunBook was fine and we started to encounter issues after the Xmas break, when we started to encounter 404 issues posting certificates into the store, issues with LetsEncrypt not being able to create non wild card domains and this issue of not being able to access a lets encrypt certificate when given the full path.
As part of our tracking down the issue, we did output the path being used and it did only show the proper path, there was no extra stuff.
After reconfiguring the RunStep to use Powershell Desktop, these issues went away and we can now publish and store wildcard and normal certificates as normal.