I am deploying 1 site that uses an SSL cert with Octupus and I have 4 other sites on the same IIS server that are not managed by Octopus. When I deploy my project it changes the bindings on the other sites to use the wrong SSL cert. Why is it jacking with the other sites??
Hi Eric,
I believe this is an issue with IIS - you can only have one SSL certificate per IP address unless you are using SNI.
When you add your HTTPS binding you’ll need to enter the specific IP to listen on and make sure this IP isn’t used by any other site.
Paul
I am not using SNI for these sites. Each have a dedicated IP address. This is really annoying. I have spent the time to automate my deployment, but I have to go onto the box and fix the SSL certificates each time I deploy. It’s also potentially costing me money as people going to my other site see the wrong SSL cert and don’t trust my site.
Thanks Eric, I’ll investigate this and keep you up to date here:
Paul
Hi Eric,
I’m having trouble reproducing this.
I have a single Tentacle with two network adapters, and so two IP addresses.
For my first package step in Octopus, I add an IIS binding with:
Protocol: HTTPS
IP Address: 10.211.55.31
Thumbprint: d7ff008470f226a4f97a7d8afee8f5c638cc9765
For my second package step, I set the binding to:
Protocol: HTTPS
IP Address: 10.211.55.32
Thumbprint: 0b7edfd9d10802e19bcb4495928a56540be5ce85
One certificate lives in LocalMachine\Personal, the other in LocalMachine\WebHosting.
When I deploy, the first step logs:
Binding: https 10.211.55.31:443: d7ff008470f226a4f97a7d8afee8f5c638cc9765
And then the second step logs:
Binding: https 10.211.55.32:443: 0b7edfd9d10802e19bcb4495928a56540be5ce85
Browsing to each IP address in my browser, I can see that the first presents the certificate it should present, and so does the second. It seems fine.
Running:
netsh http show sslcert
I see:
IP:port : 10.211.55.31:443
Certificate Hash : d7ff008470f226a4f97a7d8afee8f5c638cc9765
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : WebHosting
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
IP:port : 10.211.55.32:443
Certificate Hash : 0b7edfd9d10802e19bcb4495928a56540be5ce85
Application ID : {00000000-0000-0000-0000-000000000000}
Certificate Store Name : (null)
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Can you post some more details about what your deployment steps look like, and the full deployment log?
Paul
We are having potentially the same or similar issue. Here is the setup we have and one bit of bugginess I have found in octopus.
The servers we’re seeing this issue on have multiple certificates as well as many IP and binding combinations. They are all running 2k8 R2SP1 enterprise. Inconsistently this one sites binding ends up getting a wildcard certificate that is installed on the server rather than the intended certificate who’s subject matches the endpoint name appropriately.
Looking in the logs I can see that the thumbprint is getting matched to the intended certificate, although I don’t have the logs from the last troublesome deployment because someone deleted the release (would be awesome if the logs would stay). From what I’ve seen this happens across all 3 servers hosting this site on the same deployment so whatever the condition is it is occurring on all 3 machines when this behavior is expressed.
I can’t find anything in the deployment process that could cause this as the netsh command setting this seems pretty straight forward. I did notice however that redeploying won’t fix the issue unless I delete the site, and in turn the binding. This does turn out to be a bug in the deployment script.
If you take a look at line 180 (non SNI SSL binding) you’ll find that there will never be a case where $hasThumb.Length -eq 0 will evaluate to true.
- If the thumbprint is found $hasThumb will be a string that contains the line from the netsh output in $existing and have a length greater than 0.
- If the thumbprint is different $hasThumb will be $null and the case will still evaluate to false, thereby leaving the incorrect binding in place.
Changing line 180 and 149 to if ($hasThumb.Length -eq $null) should resolve this issue.
The next time this happens I’ll take a closer look at the log from the deployment that initially changes the binding to the wrong cert. Is there any other information you would recommend I try to capture?
Thanks for finding the bug! We’ll fix it next release:
Paul