After reading this article, you will understand why SSL certificates are used, The differences between CA signed and self-signed certificates and why working with CA-signed certificates in your testing environment is important. I also provided a tool to create CA-signed certificate for your testing environment.
Challenge
Let’s think of a situation; on a sunny beautiful day, you are sitting in your beloved cafe, drinking your favorite black coffee and out of the blue, you receive a message from Bob – whom you care about, asking you to transfer him some money via a payment service, let’s assume PayPal. So you log in to paypal and you send him the payment. In your mind, you assume:
- The website you login to was PayPal
- The money went to your friend’s account
- The sum of money you transferred is what he got, no more, no less
If any of these wasn’t accomplished, you will lose your money and trust in the service. for the service to confirm your expectations, it uses certificates
Certificates
Certificate, in a nutshell, is a file that binds the owner identity with his public key. this bond is signed and confirmed by a reliable third party which called the Certificate Authority (CA). You can think of the certificate authority as a trusted organization whose customers are web-services owners that need to issue a certificate. The CA will use its trusted key – the root certificate, to sign and issue its customers’ certificate requests. These customers need their certificates to be signed in order to be adopted and trusted by their end-users.
What is certificate needed for?
The certificate is used to ensure confidentiality and integrity of the data between two entities. Let’s name those two entities; client and server. the server is the owner of the certificate. when the client starts communicating with the server, the server will present this certificate which contains its identity.
Handshake
When the client tries to communicate with the server, such communication starts with SSL Handshake (a series of steps to validate identity and agree on a shared secret). during the handshake, the server presents his certificate to the client(figure 2 step 4). the client validates the certificate identity(figure 4 step 5) with the certificate authority. The handshake is based on the cryptographic public key inside the certificate. The identity of the cryptographic public key confirms the integrity.
The formal procedure to create a CA-signed certificate
The Client creates a key-pair (public key and private key) and a certificate signing request (CSR) which contains his identity and the public key.
The Client sends the CSR to the certificate authority organization (CA) in order to sign the request.
The Certificate Authority will verify the identity of the requester and then sign the request by binding the requester certificate with the CA certificate which called the root certificate. this bond is expressed by the intermediate layers of certificate/s. this series of certificates is called the certificate chain:
The CA will issue the chain above for public use which contains the end-user certificate up to the root certificate. the intermediate certificate is another layer of security in order to protect the root certificate. The root certificate sign the intermediate certificate which signs the end-user certificate. There could be several intermediate certificates in the chain.
Self Signed certificate
- Using self-signed certificate in testing environments is common as it is free and fast as you don’t need to wait for a CA in order to sign it for you. However, self-signed certificates act way differently than CA-signed certificates.
- With a self-signed certificate, the client must manually accept working with the certificate, whether by adding it as a trusted certificate or by ignoring the identity of the certificate owner.
- Pentesting the product with a self-signed certificate will not pass the basic security standards.
Challenges moving from self-signed certificates to CA signed certificates
- Different mechanism: With CA-signed certificate, when the client contacts the server, the certificate is validated against the trust store, which is a key-database that get updated occasionally with the valid root certificates. If your entity is working with a self-signed certificate, such a mechanism does not exist.
- Trusted or ignored: If you want your self-signed certificate to be trusted, you need to configure the certificate to be changed each time you issue a new one. However, with CA-Signed certificate, you issue a certificate under the same trusted root certificate so you don’t need to update the trusted certificates all the time.
- Deployment: Deploying a product that was working with CA Signed certificates is way easier than encountering all the necessity of updating the truststore and finding it.
Working with CA-signed certificate in your developing environment
I created a python script that can easily issue CA Signed certificates. Here is a link to GitHub
With single line command, you can generate root, intermediate and end-user certificate with the key aside.
You can also issue a certificate chain under a given root. refer to the Readme.md for more explanation.
Why this tool is only for testing?
When the user connects to your application that uses certificate chain which is generated by this tool, the SSL handshake that is done during the connection will try to validate the root certificate with the truststore. whether it is through the browser or the default client-side app truststore, this very root certificate will set there only if it was added manually, which most users don’t do that or it will be imported by the OS or the browser. The OS or the browser read the trusted certificates from public and trusted repository. a root certificate that is generated manually will not reach such places if not created by a well-known organization such as Verisign or GoDaddy…
Hesham on software 