You can use a self-signed certificate from your very own certificate authority, for deploying your application gateways and app services, with end-to-end TLS encryption. This approach should only be used for development environments, and not in a production environment. This approach is handy because it will allow you to save a lot of money on TLS certificates. Essentially you’ve be able to create certificates for your development environment, for free! I had some difficulties in doing this initially, so I’m going to share what has worked for me: Prerequisites: You will need OpenSSL, version 1.1 or higher.

  1. Create a custom self-signed openssl configuration file

This file will be used to add an extendedKeyUsage and subject alternative name property to our signed server certificate. These will be required by your app service, and your browser.

      1. Create a file named azure-self-signed-server.cnf and place it in the same directory as openssl.exe. (The name does not matter, but for this example, it will be easier to use the same names I use)
      2. Contents of the file will be below (replacing DNS.1 with the domain name you’re using the cert for. *Note you can add multiple domains like dns.1, dns.2… and so forth, if you want to secure multiple domains with one cert):
      3. [ Azure-Self-Signed ]
        extendedKeyUsage = serverAuth
        subjectAltName = @alt_names
        [alt_names]
        DNS.1 = your-domain.com

  1. Create your own root certificate authority
    This will be required by our application gateway. We will need to add the trusted root certificate authority to our gateway HTTP settings so that the gateway can secure end-to-end TLS encryption between itself and our app service.

        1. Create the root key, using command:  openssl ecparam -out root.key -name prime256v1 -genkey
        2. Create a Root Certificate and self-sign it:  openssl req -new -sha256 -key root.key -out root.csr
        3. This step will ask you for cert authority properties. Note, the common name does not need to be a domain name, and should not match what our server certificate is going to be.
        4. Generate the root certificate:  openssl x509 -req -sha256 -days 365 -in root.csr -signkey root.key -out root.crt
        5. Now, if you’re using Windows, you can double click on root.crt, and choose “Install Certificate”. Install the certificate to your Trusted Root Authorities on your machine. Either as a user or machine, either should work fine. This will ensure that you will not get browser warnings when visiting an app service that uses a cert signed by this authority. This is why this approach is only for development environments, where developers can share a trusted certificate authority.
        6. Note, you can share the root.crt and root.key files with your team, if you need to make sure anyone can sign new requests with the same certificate authority. Just make sure to keep this sharing secure.
  2. Create a Certificate Signing Request (CSR) from Azure Key Vault
    1. Navigate to an existing key vault certificate, or create a new one. The steps for generating a new one, or creating a new version of an existing cert are the same.
    2. The configuration should be as follows:
      1. Method of certificate creation: Generate
      2. Certificate Name: Name of the certificate, your choice.
      3. Type of certificate authority: Ceriticate issued by non-integrated CA (we will be using the CA we created above, to sign cert requests.
      4. Subject: cn=my-domain.com  , replacing domain with the domain that the cert will be used with.
      5. DNS Names: Add just the DNS name from the subject, example: my-domain.com
      6. Validity period: leave default at 12 months. Any longer and some browsers will show a warning.
      7. Leave everything else default, and Content Type should be “PKCS #12”
      8. Click create
      9. When you navigate back to view the key vault certificates, you will notice that the cert shows as “in-progress”. Click on the newly created/updated cert, and then click on “Certificate Operation” at the top of the portal.
      10. Click on download CSR, and move that csr file into the same directory as openssl, on your local machine. This is the certificate signing request that we will be signing with the cert authority, created earlier.
      11. Open a cmd prompt, and navigate to the directory with openssl. Run this command: openssl x509 -req -in name-of-csr-from-step-10.csr -CA root.crt -CAkey root.key -CAcreateserial -out server.crt -days 365 -sha256 -extfile azure-self-signed-server.cnf -extensions Azure-Self-Signed
      12. The previous step will create a server.crt file.
      13. Navigate back to the key vault certificate operation screen, and click on “Merge Signed Request”, upload the server.crt file, and the certificate should show as successfully created/renewed.
  3. Reference your certificate from Key Vault
    1. Ideally, you’d be deploying your app service from an ARM template or another automated process, but I’ll explain how to add the key vault certificate reference from the portal.
    2. Navigate to your app service in the portal, go to TLS/SSL Settings, click on Private Key Certificates, and then click on Import Key Vault Certificate. It will ask you which resource group, and which certificate you’d like to reference. Select the correct cert, and click ok.
    3. You’re now referencing your new self-signed certificate right out of key vault!

*Optional: Convert a .CRT to a .PFX

If you need to upload a PFX certificate, but you only have a .CRT file, this command will let you create a new PFX from your CRT.

  1. Pick a password, write it down, you will use this password to protect the new pfx. Then run command: openssl pkcs12 -export -out server.pfx -inkey server.key -in server.crt , in this case, we are converting the server.crt file to a server.pfx file.

I truly hope this blog post helps at least one person, because it took me quite a while to get this working, and there was not a lot of documentation on this exact scenario.