Deploy to IIS step rebinding https cert for a different project

[tommy.i247 (Tommy)]

We’ve setup two projects that both deploy to the same servers. Each is their own website in IIS, and each have their own (similar) process for doing so. When I deploy Project A, it sets not only it’s own HTTPS binding to the specified cert, but also Project B. Similarly, when Project B is deployed, it binds both it’s own and Project A’s cert.

There are other web applications on the same server not yet controlled by Octopus that are not affected by the rebinding.

The process we used to configure the certs:

1. uploaded both certificates to Library > Certificates
2. Created a variable set which contains a certificate variable for each certificate
3. Linked the variable set to both projects
4. Linked the Deploy to IIS HTTPs binding step to the relevant variable

We’ve checked and triple checked that each project references it’s own certificate, that the variables in the variable set reference the correct certificate, and that the certificates uploaded are the correct ones. When examining the Task Log for a deployment of Project A or B, it correctly identifies it’s own certificate and claims to set the binding. There is no mention in the log of it setting the binding for the other (wrong) project also.

Happy to provide any more information required on request (bar the certificates themselves of course).

[Kenneth_Bates]

Hi Tommy,

Thanks for getting in touch! The built-in IIS step will configure only the single site you’re deploying. How are you currently configuring it to try to rebind the other site? Perhaps you could use the following library step template written by the community to set the other sites bindings.

IIS - Add HTTP(S) Bindings

If this doesn’t help, would you be willing to expand a bit on how you’re currently attempting to do this, and maybe a bit more on your requirements? I’ll be happy to try to help reach the best possible solution.

I look forward to hearing back!

Best regards,

Kenny

[tommy.i247 (Tommy)]

Kenny,

Thank you for your response. Sorry that I haven’t been as clear as I had hoped.

The process for project A is only supposed to affect the bindings of (let’s call it the associated) Website A, whilst project B is only supposed to affect the bindings of Website B. That was my understanding of the Deploy to IIS step when I added it to the process, and I believe your understanding per your description above.

However, intent aside, these separate processes are for whatever reason affecting certificate bindings on both projects, which we do not want. I’ve explained most of the configuration above, hopefully adequately? I’ll attach some screenshots here to show the various aspects.

Project A process (Deploy to IIS, followed by various conditional notifications):

Project B process (near identical):

Project A Deploy to IIS Step:

Project B Deploy to IIS Step:

Project A Bindings:

Project B Bindings:

Project A applicable variables (same setup for B under a different domain):

Project A variable sets (same for B):

Server variable sets:

SSL Certificates Variable Set:

Server Certificates:

As you can hopefully see from all of this, I believe we’ve set this up exactly as was intended? The only difference from the norm, I suspect, will be that we use the ProjectUrl variable to determine the host on the bindings. That aspect does seem to work though in that the bindings in IIS are being set to the correct host values.

I can get you a task log if you’d like, but as mentioned in my original post, the task log claims only the site being deployed (and the site we intended) has been updated. But for some reason, the deployment sets the certificates for both projects during a single deploy, causing the site we were not deploying to be suddenly bound to the wrong certificate, which in turn makes the site inaccessible because the address/cert no longer matches. Unless we manually go in and correct one of the sites after each deploy, we tend to alternate between which site is working depending on the order in which we deploy.

For further clarity, these projects are entirely independent of one another. Project A is deployed several times per day, whilst project B is updated no more than a couple times per week. Every single time we deploy Project A, project B breaks (likewise going the other way, but per the deployment intervals, Project B is worst effected).

Hopefully that is clear enough? Let me know if you need more info.

Thanks,
Tommy

[tommy.i247 (Tommy)]

Whilst we haven’t found a solution or cause of this issue, we found that if you enable SNI on the HTTPS binding then the errors we were getting regarding invalid certificates no longer present (because the server has all the certificates available so is able to select in accordance with SNI). However, that does not resolve the incorrect certificate binding issue (now will it resolve the issue for browsers that do not support SNI).