Issue with ReadAllBytes

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\\<nnnnnnn>\!\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


We have taken the exact same script and have run it in PowerShell ISE without issue and it consistently, requests and saves Certs into Octopus.

If it help we are using 2021.3.8275 server version. when running Powershell ISE it is using the following version of powershell, 5 .1.17763.2268

The RunBooks are making use of PowerShell Core

Thanks for any info

Hi Scott,

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.

E:\Octopus Deploy\Octopus Home\Work\20220118034235-29973-368


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.


Hi @dane.falvo thanks for the reply.

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.

So happy for this to be closed

1 Like

This is fantastic news, Scott! Thanks for the update.

Congrats on the new job and feel free to reach out with any Octopus issues you have in the future.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.