Staging and SSL certs

Question

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?

Any and all advice is welcome.

Answer 1

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.

Answer 2

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?

Answer 3

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.

Thanks,

Answer 4

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.

Answer 5

-- But we do use both production and staging.

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.

Answer 6

Neil's recommendation is the recommended best practice. If you have a need for a long running pre-production environment, create seperate hosted services an test the resources there.

The current staging environments should only be used as an opportunity to do a last smoke test before performing a VIP swap to launch the application into general availability.

Answer 7

Oh I see, sorry I misread your response.

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.

Thanks for the suggestion Neil.

Answer 8

Hello Curious,

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.

Thanks,

---

Wengchao Zeng
Please mark the replies as answers if they help or unmark if not.
If you have any feedback about my replies, please contact [e-mail].
Microsoft One Code Framework

Answer 9

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.