Workarounds for problems using Jetpack and https on Azure Websites

This is a follow up post on: Moving the blog to azure web sites:

2013-07-09: Update 2 – As of Version 2.3.1 the Jetpack plugin and the WordPress cloud have  been updated to support more SSL scenarios. Jetpack should now work without issues and configuration changes. The post below is still valid for other connected systems that doesn’t like mismatched SSL certificates.


One key feature missing from Azure Web Sites is the possibility to run your own SSL certificate for encrypted https traffic.

2013-06-03: Update 1 – https, SSL and certificates for custom domain names are now launched and available (for sites running in “reserved mode”) – read more here: The information below still applies in case you don’t want to use a reserved mode site.

This pretty much disables it for any real business use whatsoever.

Every single professional I have spoken with regarding this have chosen alternate solutions for their projects and tests. As usual a key problem here is no official words on availability and firm delivery dates to relate to. Finding a blog post or discussion thread where someone says it might be available as a feature in the future just doesn’t enable project budgets to be spent on Azure Web Sites even for tests and explorations.

(Also, please note that Azure Web Sites is currently still in Preview mode.)

But for a personal blog like this the need for ssl is not as absolute. However, some 3rd party tools and features still use it and will complain if the certificate is missing or has errors. For WordPress, one such feature is the JetPack plugin. This will work for sites that doesn’t have any certificate at all, but when running on Azure there is a standard ssl certificate available and used for all sites. This certificate uses the * wildcard certificate.

This means that when you try to connect to your site using https, you will receive an error:


Screen shot of certificate error.

This error will eventually break JetPack integration and some functionality such as publicize.

There are several discussion threads on this issue and Microsoft representatives have stated that a native feature for ssl in Azure Web Sites will be available in May 2013.

There are a few workaround options available here:

1, disable the cURL transport for the site

as described in this post:

If you enable the protocol again after connection then some features will work and some will fail.


Screen Shot of cURL configuration in Core Control

2, disable the use of https in the JetPack configuration.

This will force JetPack to use http instead and no certificate errors will disable any features.

Please note that changing the plug in files directly will probably trigger any security plug ins that you might be running and the changes will be overwritten every time you deploy an update to the plugin

To change the plugin, log in to the blog dashboard and navigate to Plugins -> Editor.

Select Plugin to Edit: Jetpack by and hit select.

Navigate to the following line and update it so that it looks like this:



Screen shot of configuration change.

The only change is to remove the s in https so that the protocol used is http.

3, use the address for your site.

By using the pre-provided address the certificate will match the site address and https should work without issues.

This might not be very useful if you rely on the actual address somewhere, such as if you migrate a blog or if you expect users to enter it in a browser.

I am currently using this approach for some apps that require https but where actual address doesn’t matter.

4, Last, to be fair, there is an alternate workaround.

Described here: It is however not really a valid option for me at the moment.

One thought on “Workarounds for problems using Jetpack and https on Azure Websites

  1. Pingback: Moving the blog to Azure Web Sites | Stefan Johansson

Leave a Reply

Your email address will not be published. Required fields are marked *