Since the staging environment in Azure gives you a unique DNS name for each deployment, how does one deal with SSL certs that will fail the domain name test? I know in the browser I can choose to bypass this error but some client apps don;t allow this, particularly
when connecting to web services.
So what is the best practice for dealing with this? Are people using something like the windows hosts file to temporarily remap the correct DNS name to the IP address of the staging deployment? Or are there other techniques for dealing with this?
Our issue comes down to QA. When we deploy to staging QA does their normal regression tests and the SSL cert error is a bit of a roadblock.
Also, if I were to create two web sites in one WebRole and use HostHeaders with a single wildcard SSL cert, how would I handle the staging issue?
I think the solution to this is to use two hosted services - one for production and one for regression testing. That way you can keep the staging slot for "staging" a deployment prior to performing a VIP swap. It is possible to purchase an SSL certificate
pretty cheaply these days - I spent less than $50 on one, for example.
But we do use both production and staging. I am referring to the fact that each time we go to deploy a new version of our app we first put it in staging so QA can run their tests. Once the tests pass we VIP swap. The problem is that testing in staging results
in the SSL cert failures. Our QA group would like clean test results with no special 'bypass the cert warning' steps. Plus our web services can be troublesome.
This must be a common problem, so how do people generally deal with this?
Since SSL certs are relying on domains, I think it is not the fault of Azure. Domains are used to identify your services. Maybe using two certificates will solve the problem, one for staging, another for production. When swap VIP, the configuration
might need a updated too.
Wait.. If we use HostHeaders in our web sites and we have deployed the same project on both production slot and staging slot, since one domain name will map to one IP address one time, it is almost not possible to access staging and production environment
at the same time. Because if we have set a host header for a web site, we do need to use that domain name to access that site.
So I am afraid maybe changing the host file would be the only one walkaround for this case. If we does not point the domain to the staging service, it can not be reached because of the host headers.
But I can't purchase an SSL cert for cloudapp.net, so there is no way I am aware of to get a true SSL cert that works in staging. I am really wondering what others are doing to deal with this scenario, surely this is common.
I was suggesting using production environments in two hosted services for which you can get valid SSL certificates. Once testing is completed in the test production environment, you deploy that application package with the correct configuration file to
the staging slot of the production environment, do some smoke tests, and then a VIP swap.
Ok, that does seem like a reasonable approach. I guess the only thing I don't like about it is that I do need to deploy again to staging and run smoke tests before I can actually deploy to production. But I might be able to live with that.
Actually I think there is a better solution. When we test locally we can just map productionURL to staging slot IP by setting local host file. In this way when client app or browser access productionURL it will access staging app. Since the cert is for productionURL
it will successfully pass validation without showing any warnings.
A similar approach can be achived by using what is common called a c-name DNS swap. Instead of performing the vip swap, you instead change the external DNS c-name record that points to your services. Both approaches have their pros/cons so its up to you
to pick the right one for your needs.