SSL Detective allows you to easily see what certificates are being used to verify a server and encrypt the connection. This software can help you determine if there are trust issues and allows you to email the certificates for further research.
When an iOS device first connects to a server that is secured using SSL, the server provides its SSL certificate and, optionally, other certificates to verify the server’s identity (a certificate chain). If the first certificate in the chain (the root certificate) is not trusted by the device, the server’s certificate will not be trusted. If the chain is not trusted by iOS, services that depend on it (like Safari or Mail) will fail or prompt the user to accept an untrusted chain. In order to trust the root certificate, iOS devices ship with a root certificate store that contains the trusted root certificates. An administrator can install root certificates on an iOS device so that other certificate chains can be trusted as well, either by using configuration profiles or manually installing via email or a website.
One of the key security pieces of the Internet is Secure Socket Layer (SSL) which allows a device to securely connect to a server (such as your bank’s website), and trust that server belongs to the bank and no one can eavesdrop on the conversation. To accomplish this, SSL certificates are used by iPhone and iPad to verify that the server is the one identified by the certificate, trusted by a Certificate Authority. If there are any inconsistencies in determining this information, the connection may fail or the user may be given a warning.
Troubleshooting issues with certificates and certificate chains can be difficult on iOS. When using Safari on iOS to connect to a website secured with SSL that has a certificate-related issue, Safari will only show you part of the server’s certificate, not the entire certificate or the certificate chain. SSL Detective makes viewing the certificate and certificate chain much easier on iOS.
SSL Detective connects to an SSL enabled port and downloads the server’s certificate as well as any other certificates provided. It then verifies the certificate chain via iOS and the root certificate store, getting back the entire chain including the root certificate and any other certificates (intermediates) that are downloaded. This allows you to see a fully trusted certificate chain or where the SSL trust is failing on an iOS device.
SSL connections are not limited to only web servers. An SSL port can be used with Mail (IMAPS), VPN, directory service (LDAPS), and others. SSL Detective allows you to view the certificate chain for errors such as certificate expiration dates and hostname issues.
The following examples show a well-formed certificate chain, an untrusted root error, and no intermediate certificate error. All of these examples are live and can be used with SSL Detective so you can look at problems more closely.
Example 1: Well-Formed Certificate Chain (twocanoes.com:443)
In the first example, connect to twocanoes.com port 443 and view the certificate chain. The top of the certificate chain says “Certificate Chain Trusted”; this is in green to visually inform you that everything in the chain is correct. The twocanoes.com server on port 443 is set up to return the intermediate certificate (①) and the server certificate (②). The server’s certificate is trusted because the Certificate Authority is trusted by default in iOS. If you want to email the certificates on another device or import a root certificate into a certificate store, press “Email Certificates” (③) to email yourself a copy of the certificate chain.
Example 2: Untrusted Root (twocanoes.com:444)
In this example, the root certificate is not in the certificate store, and is expired. Note that the top of the certificate chain says “Certificate Chain Not Trusted”; this is in red to visually inform you that everything in the chain is not correct. This results in a certificate chain that is not trusted.
Example 3: No Intermediate Certificate (twocanoes.com:446)
In this example, the server does not return an intermediate certificate that is required and the intermediate cannot be downloaded. This causes the chain to fail (①) even though the root certificate is in the trusted root certificate store. The intermediate certificate authorities certificate should have been downloaded from the URL (②), but access to that URL was blocked by the network. This could be resolved by allowing this connection or by having the server provide both the intermediate certificate and the server certificate.