I created a certificate by using Microsoft Active Directory Certificate Services, provided by my network administrator for this purpose. Here’s what the UI looks like:
I don’t have to deal with getting clients to accept the CA, since AD takes care of that.
It’s (relatively) easy to use.
Cons:
There doesn’t appear to be any way to script this.
I have to create a certificate request on the target web server.
This also means I have to complete it on that server, which means that it will be installed at the end of the process, negating some of the benefits of storing the certificates in Octopus.
These certificates don’t appear to work with the Octopus Certificates feature.
To that last point, here is a certificate as loaded into Octopus:
To me, it looks like it is installing the certificate into one store, and then trying to look for it in another.
It’s worth noting that if I set the binding using the thumbprint directly instead of a certificate variable, there is no problem. That’s how we are using certificates in all of our environments today, but we get none of the advantages that the Certificates feature provides.
How do I make this work, or where did I go wrong?
I’d also like to understand how others are approaching this problem. For production certificates, we are obviously getting those issued from an external CA, and these should work with the Certificates feature without issue. It’s the task of generating certificates for our non-production environments that will work that concerns me. I have used makecert.exe before, but that had the disadvantages of having to get a CA cert installed to all of the clients, plus no central place to issue certificates from, resulting in me becoming the “cert guy” every time someone needed a new certificate. I looked into Let’s Encrypt, but it seems that a public URL is a prerequisite, and our non-production environments are explicitly non-public as well.
Are there any options out there that make it easy to generate self-signed certificates without a lot of back-and-forth (CSR) that work well in Octopus for non-production environments?
Hi,
Thanks for getting in touch and providing us your experience with implementing your own Public Key Infrastructure (PKI) in your Octopus environment.
Based on the screenshot, I’m noticing that the certificate loaded into Octopus has no private key which could point to issues here. I believe both the certificate needs to exist and the private key must be available if it will be used in this way.
I’m also very interested to hear what other’s in the community use for generating non-production certificates. Personally I tend to use let’s encrypt certificates in both production and non-production environments especially because of the immense planning that must take place to implement an effective PKI. Since you already have your own on hand, it’s perhaps the better option.
Figguring out how to trust self-signed certificates is a pain, this is why a good PKI is very powerful here as ideally each client in your organization already trusts the Root Certificate and therefore the end-entity certificate of your web servers, etc.
I hope this has helped to get to the bottom of why we can’t find the certificate in the store. I look forward to hearing if the private key was the issue here.
Can you elaborate on how you do this? My understanding was that LE won’t issue a certificate to a non-public hostname. I’m using names like website.dev2 or api.company.qa to make it clear to testers which environment they’re in.
Hi,
Thanks for keeping in touch! I believe it’s now a standard across the board that a public Certificate Authority won’t issue publicly trusted SSL Certificates for non-routable domain names (.local, .corp, .lan for example).
One way around this is to configure all new AD domains with publically routable DNS Names as opposed to non-routable ones. In this case, you set a root domain of ad.corp.com and your web servers might look something like dev-website.ad.corp.com. Only your internal DNS servers will know that ad.corp.com exists (similar to how we configure non-routable domain names) so you wouldn’t need to worry about someone from the Internet accessing servers through ad.corp.com as those records won’t exist publically.
The advantage is that you can still request certificates from Let’s Encrypt and they’ll work. I hope this has been helpful! I look forward to hearing from you if you have any other questions.
It looks like the certificate is working, but I first have to export it from the web server(IIS) with a private key before I can add it to Octopus. This should work for us, but I’d still like to be able to automate this at least to the point where I could create a large number of certificates in a batch.
Hi,
Thanks for keeping in touch! I’m glad to hear that your certificates are working. One potential way to automatically import your certificates into the Octopus certificate store could be to use Octopus Client, which will perform this task via the Octopus Rest API
We have a script which you can check out on github which will use the Octopus Client to create a certificate in Octopus for you, provided you have the pfx file.
I look forward to hearing if this is something that might interest you.
