I’ve stumbled across two issues with certificates I was wondering if someone can assist with.
Octopus allows multiple certificates with the same “name”. I stumbled across this when scripting adding certificates into Octopus and realized that we had two with the same name in Octopus. The certificate was identical in all regards other than one of the entries was scoped to two environments and the other certificate was scoped to 3 environments. Was this by design?
Should the audit log show when a certificate gets archived? While I was working on the script to handle multiple certificates the “duplicate” that wasn’t updated was archived by something/someone. However, I do not see an entry in the audit log for the archive. I was hoping to see how/why it got archived.
On a side note, I’m using the Octopus.client to replace certificates in Octopus. I used ReplaceCertificate as my example. It appears that the line:
$repository.Certificates.Replace($currentCertificate, $pfxBase64, $pfxPassword);
does not allow you to pass a secure string for the pfxPassword. It works with clear text, am I doing something wrong?
Thanks for getting in touch. I’m not sure if allowing duplicates on the name was specifically by design or not, it’s certainly been that way since the start from what I can see in our code history.
Regarding the audit log, when a certificate is replaced, the original is archived. So the audit log entry that says the certificate got replaced implies the existing one was archived.
How was the script updating the certificate? Looking at the server code, the replace is based on an Id, so I’m not sure how it would replace the wrong one. Is the script maybe selecting by name first? This is the only thing I can think of at the moment that could lead it to the wrong one. The “something/someone” also has me curious, I’ve checked and normally when you do a replace the user who did the replace appears correctly in the audit log against the “was replaced” entry. Are you seeing a different user, or system or something like that?
Finally, regarding SecureString, our client library only uses strings. So you aren’t doing anything wrong, that’s how our client has been written. While researching some background to this I did find this documentation from Microsoft and a related link about SecureString not being recommended. So using string is by design and I think any change to that would be unlikely.
Hi Shannon,
Thanks for the response! Thanks for the inforamtion on SecureString, I hadn’t run across that not being recommended. I’ll plan accordingly.
To answer your questions:
How was the script updating the certificate?
The first iteration of the script was pulling the certificate name from the pfx file, convert that to a base64string, and then search for that name in Octopus. Capturing that in a variable. If an Octopus certificate with that name is found I then following line to replace the certificate.
$replacementCertificate = $repository.Certificates.Replace($currentCertificate, $pfxBase64, $certpw);
(Using the Octopus Client library.)
Doing that, only 1 of the multiple certificates got updated. (Working on refactoring that to compensate for duplicates and put some additional checks in, such as comparing thumbprints to see if it was already updated and such.)
Knowing that duplicates have been allowed is fine, my second iteration will compensate for multiple certificates. (Though I’ll push my teams not to use duplicate certificate entries in Octopus, unless they can provide a good reason as to why.)
Looking at the server code, the replace is based on an Id, so I’m not sure how it would replace the wrong one. Is the script maybe selecting by name first? This is the only thing I can think of at the moment that could lead it to the wrong one.
As mentioned above, you’re right, it is.
The “something/someone” also has me curious, I’ve checked and normally when you do a replace the user who did the replace appears correctly in the audit log against the “was replaced” entry. Are you seeing a different user, or system or something like that?
To be clear, I had two identical certificates when I ran the first iteration of the script. That script updated 1 of the 2 certs with the new information. The “something/someone” came in when that second script which wasn’t updated got archived… I did not see anything in the audit log showing what caused the second script to get archived. The certificate that did get replaced with the script did have an audit trail that showed it getting archived as part of the replace action. I was reporting that as an issue. Oh, and yes the updates are being made using a service accounts API key. Whereas when I’m looking in the audit log with my account which is an administrator.