Five Tips for Using Self Signed SSL Certificates with iOS

calendarDecember 12, 2013 in HttpWatch , iOS , SSL

SSL certificates are relatively cheap to purchase, but sometimes it would be easier if you could create your own. You might need to setup SSL on development and test servers that have different host names or on systems that will only ever be accessed on your local network.

Self-signed SSL certificates allow you to quickly create certificates for free, without having to pay a Certificate Authority (CA) or comply with any auditing requirements.

The downside of using self-signed certificates is that browsers will not automatically trust sites that use them. In Mobile Safari you would see an error like this:

Self-signed error in Safari

The HttpWatch iOS app provides some more detail:

Self-signed error in HttpWatch App

The rest of this post provides tips on how to setup iOS to avoid these errors and how to simplify the creation and management of self signed certificates.

Tip #1 – Don’t Accept your Self-Signed Certificate in Mobile Safari

It’s tempting to just select Continue or Details->Accept when you first try using your self-signed certificate in Safari:

Don't Accept Safari SSL Exception

This would allow you to open the site in Safari, but there are two significant downsides:

  1. Accepting the certificate in Safari just adds an SSL exception that prevents Safari warning you about the site. It doesn’t install the certificate as a trusted certificate on iOS. Any other apps (e.g. Chrome, HttpWatch, etc…) on the device will still fail to connect to the site.
  2. Once the SSL exception is added there doesn’t seem to be a way to remove it in iOS 7. In previous versions going to Settings->Safari and selecting ‘Clear Cookies and Data’ would delete it. This no longer seems to work in iOS 7 (please leave a comment if you know how to do this).

Tip #2 – Install Self-Signed Certificates as an iOS Configuration Profile

You can add an SSL certificate to the trusted list in iOS by simply emailing the file to yourself as an attachment:

Email SSL Certificate

Then select Install to add the certificate. Once you’ve done this you use the certificate without warnings in Safari or other iOS apps that use the device’s keychain..

Also unlike Safari SSL exceptions, you can access the certificate at any time in Settings->General->Profiles and remove it if required:

Trusted Certificate in iOS

Apple provides an iPhone configuration utility for Mac and PC that can also install certificates. This would be a better option where email is not available or you have a larger number of iOS devices to manage.

Tip #3 – Don’t create Self-Signed Certificates within IIS

Creating self-signed certificates in IIS appears to be easy. You just select the ‘Create Self-Signed Certificate’ menu item:

IIS Self Signed Certificate

Unfortunately, IIS uses the computer name as the host name in the certificate:

IIS Certificate Host Name

It most cases the computer name will not match the intended host name and you end up with a self-signed certificate that is never trusted – even when it is added to iOS:

Untrusted Certificate

It’s possible to fix this problem by installing and running the SelfSSL tool from the IIS 6 Toolkit. However, it’s probably easier just to use OpenSSL as described in the next tip.

Tip #4 – Creating Self-Signed Certificates with OpenSSL is Easy

One of the easiest ways of creating a self-signed certificate is to use the OpenSSL command line tool that is available on most platforms and installed by default on Mac OSX.

First create a private key file:

openssl genrsa -out myselfsigned.key 2048

Then create the self signed certificate:

openssl req -new -x509 -sha256 -key myselfsigned.key -out myselfsigned.cer -days 365
-subj /

You can use any filenames you like for the key and certificate (.cer) files. The /CN parameter needs to be set to the required hostname (e.g. for in the example above). The days parameter specifies the expiration date as days from today’s date.

There’s even a site to do this if you don’t feel like downloading OpenSSL, but of course it’s more secure to do it yourself.

On Apache servers the key and certificate file can be used directly in your SSL configuration. With IIS you need a PFX file so that you can import the certificate into the Server Certificates section of IIS. OpenSSL can create the PFX file for you as well:

openssl pkcs12 -export -out myselfsigned.pfx -inkey myselfsigned.key
-in myselfsigned.cer

Tip # 5: Consider Creating Your Own Certificate Authority (CA)

One problem with self-signed certificates is that you’ll need to set up trust relationships for each certificate on each device. An alternative is to create your own Certificate Authority (CA) root certificate and then create certificates based on it.

Instead of paying a commercial CA to create SSL certificates on your behalf, you are acting as your own CA. The advantage is that your custom CA certificate only has to be installed once on each device. The devices will then automatically trust any certificates you issue based on your root CA certificate.

Creating the CA certificate is a simple two step process. First create a private key file as before:

openssl genrsa -out myCA.key 2048

Then create the certificate:

openssl req -x509 -sha256 -new -key myCA.key -out myCA.cer -days 730
-subj /CN="My Custom CA"

The certificate file (myCA.cer) created above can be publicly shared and installed on iOS or other OS’s to act like a built in trusted root CA. Custom CA certificates on iOS are also stored in General->Settings->Profile:

Custom CA on iOS

The private key file (myCA.key) is only used when creating new SSL certificates.

You can create as many certificates as you like based on this CA certificate. There’s an extra step involved because you have to create a CSR (Client Signing Request) as if you were purchasing a commercial SSL certificate.

First you would create a private key:

openssl genrsa -out mycert1.key 2048

and then create the CSR:

openssl req -new -out mycert1.req -key mycert1.key -subj /

Then use the CSR to create the certificate:

openssl x509 -req -sha256 -in mycert1.req -out mycert1.cer -CAkey myCA.key
-CA myCA.cer -days 365 -CAcreateserial -CAserial serial

The certificate created (mycert.cer) can be installed on a web server and accessed from any iOS device that already has the CA certificate installed.

UPDATED September 24th, 2015 – The OpenSSL certificate creation commands now include the -sha256 flag to avoid browser warnings about the use of  SHA1. This tip was provided in a comment by Giancarlo Gomez – Thanks

You can check SSL/TLS configuration our new SSL test tool SSLRobot . It will also look for potential issues with the certificates, ciphers and protocols used by your site. Try it now for free!

How Secure Are Query Strings Over HTTPS?

calendarFebruary 20, 2009 in HTTPS , HttpWatch

A common question we hear is “Can parameters be safely passed in URLs to secure web sites? ” The question often arises after a customer has looked at an HTTPS request in HttpWatch and wondered who else can see this data.

For example, let’s pretend to pass a password in a query string parameter using the following secure URL:

HttpWatch is able to show the contents of a secure request because it is integrated with the browser and can view the data before it is encrypted by the SSL connection used for HTTPS requests:

If you look in a network sniffer, like Network Monitor, at the same request you would just see the encrypted data going backwards and forwards. No URLs, headers or content is visible in the packet trace::

You can rely on an HTTPS request being secure so long as:

  • No SSL certificate warnings were ignored
  • The private key used by the web server to initiate the SSL connection is not available outside of the web server itself.

So at the network level, URL parameters are secure, but there are some other ways in which URL based data can leak:

  1. URLs are stored in web server logs – typically the whole URL of each request is stored in a server log. This means that any sensitive data in the URL (e.g. a password) is being saved in clear text on the server. Here’s the entry that was stored in the server log when a query string was used to send a password over HTTPS:

    2009-02-20 10:18:27 W3SVC4326 WWW GET /Default.htm password=mypassword 443 ...

    It’s generally agreed that storing clear text passwords is never a good idea even on the server.

  2. URLs are stored in the browser history – browsers save URL parameters in their history even if the secure pages themselves are not cached. Here’s the IE history displaying the URL

    Query string parameters will also be stored if the user creates a bookmark.

  3. URLs are passed in Referrer headers – if a secure page uses resources, such as javascript, images or analytics services, the URL is passed in the Referrer request header of each embedded request. Sometimes the query string parameters may be delivered to and stored by third party sites. In HttpWatch you can see that our password query string parameter is being sent across to Google Analytics:


The solution to this problem requires two steps:

  • Only pass around sensitive data if absolutely necessary. Once a user is authenticated it is best to identify them with a session ID that has a limited lifetime.
  • Use non-persistent, session level cookies to hold session IDs and other private data.

The advantage of using session level cookies to carry this information is that:

  • They are not stored in the browsers history or on the disk
  • They are usually not stored in server logs
  • They are not passed to embedded resources such as images or javascript libraries
  • They only apply to the domain and path for which they were issued

Here’s an example of the ASP.NET session cookie that is used in our online store to identity a user:

Notice that the cookie is limited to the domain and it expires at the end of the browser session (i.e. it is not stored to disk).

You can of course use query string parameters with HTTPS, but don’t use them for anything that could present a security problem. For example, you could safely use them to identity part numbers or types of display like ‘accountview’ or ‘printpage’, but don’t use them for passwords, credit card numbers or other pieces of information that should not be publicly available.

You can check SSL/TLS configuration our new SSL test tool SSLRobot . It will also look for potential issues with the certificates, ciphers and protocols used by your site. Try it now for free!

Ready to get started? TRY FOR FREE Buy Now