Finally, a Solution to HTTPS-ify Your Localhost that Works

Presented by Hugh Smith on 07/23/2018 2:00pm

Making Localhost SecureSetting up HTTPS locally can be a little bit tricky. You may manage to get your self-signed certificates installed, but you still end up with those pesky browser privacy alert. In this webinar, we walk through setting up our own Certificate Authority (CA) - not just the self-signed certificates and show some nice little tricks to keep it simple while eliminating the browser privacy alerts.

We will show how to easily get all of our localhost sites to run under HTTPS, and discuss the reasons why we would want to have HTTPS on our localhost in the first place.

In this episode of Web Wonders, we will create our own Certificate Authority (CA). We'll show how to have browsers/computers ‘trust’ our certificates without having to add any exceptions or get any of those pesky browser errors. We'll discover how to generate and sign our newly created CA in a single, multi-domain certificate that includes all of our localhost domains within it.

It doesn't matter if you use a Windows PC user or a Mac PC user because this webinar demonstrates the setup of a domain in XAMPP for Windows users and a domain in MAMP Pro for Mac users.

But perhaps the most interesting highlight (and the OwnWP member exclusive) is the first peek and access to Hugh Smith's Dev Helper Cert Manager (beta) that makes the certification generation process almost automatic.

Are you are already running your development area in HTTPS but are still getting those pesky browser privacy alerts. Have you noticed that we can no longer add the exception in the most popular browsers? Reason being is that the top level browsers (Firefox being an exception) have dropped support for commonName matching certificates.

According to DNS Simple, “The common name represents the name protected by the SSL certificate. The certificate is valid only if the request hostname matches the certificate common name. Most web browsers display a warning message when connecting to an address that does not match the common name in the certificate.”

Why Use HTTPS in a Local Environment?

Enough time has passed for us all to know that our production website environments need to be protected with HTTPS. But, what about our development areas? Long story, short, yes.

If you’ve been running a local development environment you should run that environment as securely as possible. Our development areas, even on localhost, can benefit from being hosted in an HTTPS environment.

But the primary reason developers use a local environment for development is to test everything, to resolve any problems, and experience no surprises before the site goes live.

If you want things to display and act as you have developed them in your development area once you move the website into production, then you want the environment that you are developing in to be as similar as possible to that of where the site will reside upon launch.

When your environments are not as similar as possible, the risk is greater and you invite more issues to show up in your live production site that may not have shown up in your development environment – especially when the development site is HTTP and the production site is HTTPS.

The Old Way of Creating a Self-Signed Certificate

Creating a Self-Signed Certificate Version 1

Similar to enabling HTTPS on a production site, you first need a certificate. For a production site, you request one from a certificate authority like Let’s Encrypt, Comodo, etc. For a local dev environment, you can generate a self-signed certificate on the command line through your computer’s terminal utility. It used to be as simple as this command:

Self-Signed SSL Certificate - Old Method

Run the command and answer the questions:

Self-Signed SSL Questions

If you have your file paths open you will notice that completing the questions creates the certificate as well as the key file.

Most of the questions are not pertinent to a development environment. When looking at the certificate information, the only information that used to be really important was the CommonName (CN). The importance to the CN was that it determined which domain the certificate was valid for.

But now, the CN is also basically irrelevant because modern browsers ignore it when matching a domain name to a certificate. Sadly, the effect of the browsers ignoring that information results in those pesky privacy alerts.

Creating a Self-Signed Certificate Version 2

You can run the same command but this time we need to define the CommonName.

CommonName in New Way of Adding SSL Certificate to Localhost

We use XAMPP to illustrate that it is running and we can add everything we need to our vhost file. We simply need to tell our file where to look for the SSL Engine

Changing the Path to the File and Key

But still… even if we can add an exception, we still cannot get the green padlock and it appears our site is less than ideally secured.

A Better way of Creating a Self-Signed Certificate

Create a directory that contains the names of all of your development website domains within the TLS directory of your localhost development site directory. In our example, the domains file is called domains.cnf

We have also created a script called which is a bash script that outputs our dev.crt

The script can include instructions to your browser to trust that CA.

Introducing the Dev Helper App

The Dev Helper App is developed by Hugh Smith. This tool will help us to create our root certificate which allow us to sign other certificates.

Anything webkit, ie Chrome, Safari, and so forth, will look at the keychain on a Mac to determine whether or not the root certificate (or whichever certificate is being used) is trusted. Firefox works slightly differently in that you can add the exception separately.

Let’s create our certificate using Dev-Helper

  1. Point to where you want to output your results. In our example we want it to go into the TLS directory.
    Dev Helper Output Directory
  2. Create the Certificate Authority (CA)
    Creating the Certificate Authority

    1. CA File Name
    2. The country, state, and city information can typically be anything you want to add
    3. Common Name – you choose what name to use. In out example we used the A A for simplicity and so that the name would appear at the top of out list in Firefox for demonstration purposes.
  3. Click on Generate CA once all the fields are completed.
    Generating the CA in the Dev-Helper created a directory folder. Within the folder is your root certificate and your key that contains everything you need.
    Root Certificate
  4.  You can import the certificate into Firefox and check all the tick boxes to trust the certificate for any purpose.
  5. Moving back to the Dev-Helper we can do to the “Multi-cert” tab of the App and complete this section with our data. The Name and Domain area of this form can be anything you want to use. Click Save Cert Settings
    Multi-Cert Form information
  6. After saving, add your domains to the left column.
    Domain List for our Multi-CertAny domain listed here will be included in our SSL Certificate. Click Save Domains.
  7. Click Generate Multi Cert. What we have done is create a certificate that is signed by our root certificate. Both the new multi-cert and the multi-cert key are now located in that same TLS directory where we had created the root certificate. The key is not really needed but having the cert that is signed by our other (root) certificate is what we were after.
  8. Next, we need to tell XAMPP where to look (by changing the path in our vhost file, like we had demonstrated earlier in one of the old way versions) for the new multi-cert certificate.
    Multi-Cert path for XAMPP vhost file
  9. Restart Apache on XAMPP
  10. Refresh your localhost and you should see that it is now HTTPS, you have a green padlock, and there is NO alerts, warnings, or errors.

When taking a look inside the Multi-Cert you can see that t is verified by our Authority. Looking at the Security,  and View the Certificate itself you can see that it does have the Common Name as we named it during the creation of the Multi-Cert certificate. It is NOT the name of the domain that we are on but that is ok because you can see when you go into the details that what we are doing is using the extension and the Subject Alt Names of the certificate.

If you have ever looked in the details of the Cloudflare certificate, you would notice that it is created in the same fashion.

The Dev Helper App is currently only available for Macs, however, the roadmap is planned, 99% of the code is already compatible and will be able to be reused, and the Windows version will eventually be available.

Installing the Certificate Using MAMP

  1. Open MAMP and choose the SSL tab
  2. Click the + in the lower left corner to create a new host
  3. Add your Host name (again, this can be anything you want to use as your domain in your dev area)
  4. Click on the folder icon to select where you want to direct the path to
  5. Choose the location in the directory
  6. Click Create
  7. Deselect the host file
  8. Repeat the entire process #2 – 6. MAMP needs to create 2 listings to handle this part
  9. Select SSL tab
  10. Tick SSL tick box
  11. Click folder icon within Certificate File
  12. Point to the directory path that leads to our root certificate
  13. Click Choose
  14. Click folder icon within Certificate Key
  15. Point to the directory path that leads to our root certificate key
  16. Click Choose
  17. As long as your domain is already added to the dev-Helper, then you can click save.
  18. Restart Apache on MAMP
  19. Refresh your localhost and you should see that it is now HTTPS, you have a green padlock, and there is NO alerts, warnings, or errors.

Adding the Certificate to macOS Keychain

There is still one thing that is left to do. We need to add the certificate authority to our keychain.

Open Utilities and find your Keychain Access. Open the Keychain Access. In your Keychain Access left menu navigation, click Certificates and then Login.


Drag and drop the root certificate file into the Keychain Access’ main area.

Drag and drop the CA into the Keychain Access

Once the certificate file is dropped into your Keychain Access, search for and double-click on your certificate. A window will open with the certificate details.

Expand the Trust section. Change the “When using this certificate:” select box to “Always Trust”.

When you close the certificate window, you will be prompted to enter your password to confirm your action – which you will want to do. Now visit your dev site again. Your localhost is now HTTPS, you have a green padlock, and there is NO alerts, warnings, or errors.

To clean up, you may choose to delete the certificate file from the folder you dragged it into. Since you’ve added it to your system’s keychain, it is no longer required to remain in the folder.


Using Dnsmasq for local development on OS X

DNSAgent – A powerful “hosts” replacement.
Buy MAMP IT UP: A Guide to Installing WordPress On Your Mac: Read 6 Kindle Store Reviews –
WAMP It Up! WAMP It Up! eBook: Arelthia Phillips: Kindle Store

Presenter Bio: Hugh Smith

Hugh Smith has been doing freelance work and building his own successful web development (among other things) business for years. Hugh is not from Australia. The Oz comes from Hugh's roots in Kansas, and though he also says that he is not a wizard, we're here to tell you that this is one man behind the curtain you're going to want to pay attention to.