Octopus Deploy utilizes X.509 certificates to allow for secure communication between the central Octopus server, and the remote agents running the Tentacle service. Upon installation, both services generate a self-signed X509 certificate. An administrator then establishes a trust relationship between the two by exchanging the public key thumbprints of each service to the other.
This is a common security model in B2B applications, and it means both services are able to authenticate without exchanging a shared secret or password, or being on the same active directory domain.
But dealing with X.509 certificates on Windows is, well, a pain in the ass. It's the source of a lot of bug reports. In this post, I'm going to share what I've learned about dealing with them so far.
Tip 1: Understand the difference between certificates and PKCS #12/PFX files
In .NET, the X509Certificate2 object has properties for the PublicKey and PrivateKey. But that's largely for convenience. A certificate is something you are supposed to present to someone to prove something, and by design, it's only the public portion of the public/private key pair that is ever presented to anyone. When an X509 certificate is presented to someone, .NET of course strips out the private key. Having the private key property on the certificate object is a bit of a misrepresentation, especially since, as we'll see, there's a big difference in how the public and private key are dealt with.
Read more: Paul Stovell
QR: 