Use devcert or similar strategy for for ssl certificate generation

[swrobel]

This issue is for a:

• bug
• feature request
• modification request

Expected Behavior

Generated certificate only needs to be trusted once instead of the current process from webpack-dev-server of having to go to Advanced and Proceed (unsafe) every time a new cert is generated.

This was discussed on webpack-dev-server as a suggested change for 3.x (which I now believe has morphed into this project)

Actual Behavior

No certs generated (at least that I can see in the current code, so this is up for discussion.

New Feature Use Case

Make sure everyone uses local SSL for development!

[shellscape]

Thanks for the issue 🍺

devcert is actually going to be the preferred method to use for generating these. webpack-serve is not going to handle that task, and will only consume certs as provided. We're working with the devcert maintainers to bring a solution to everyone that's more user-friendly. I'll update the README in the meantime. Please feel free to reply and continue the discussion.

[davewasmer]

Hey, devcert author here, just chiming in that it's the next thing up on my OSS todo list. There's a few changes that needed to happen to make sure we are doing things securely, and testing is a bit of a bear (as you might imagine).

Thanks for everyone's patience (especially @shellscape's) while I work through these issues. Hopefully we can close this out soon!

[rubencodes]

Hey all,

I'm in unfamiliar waters here so apologies in advanced for the naive noob question: what's preventing this project from just having an ssl: true option that uses whatever tool under-the-hood to generate a cert on-the-fly?

[davewasmer]

@rubencodes you could, but you browser wouldn’t trust that certificate, so you’d see annoying warning pages where your browser tells you “This isn’t safe, I don’t know whoever made this certificate”.

To avoid that, you need to tell the browser to trust the certificate you generate, which requires sudo/admin level privileges (as it should). That process of telling the browser to trust a certificate also varies across platform and browser.

Devcert is a library that manages all that for you, so you can just say “give me a trusted certificate” and it will do the legwork of promoting the user for permission and updating the various browser and OS level trust stores.

So, you’re on the right track, but it’s slightly more complicated in the “under-the-hood” part ;)

[shellscape]

@rubencodes the complexities that come with an under-the-hood approach make it undesirable. webpack-dev-server is still dealing with an imperfect solution. Couple that with the fact that most folks who actually need to test on SSL have their own certs already, and you only create an environment of complexity for the end user by auto-generating one. Users should also know what SSL is and what it means before they arbitrarily choose to test using it. So webpack-serve takes the approach of insisting that users understand what they're doing, while providing an easy means to do so (that's where devcert comes into play).

webpack-serve isn't a kitchen-sink solution. it's a solution that enables you to easily apply and use the kitchen sink if you'd like to.

[rubencodes]

@davewasmer @shellscape Gotcha, great answers all around! Thanks! These days switching a production website over to HTTPS can be as simple as checking a checkbox or running a single command (i.e. complexities hidden away from the end-user), so I was just curious if there was a way to do this with our local dev servers as well. Totally makes sense not to take the kitchen-sink approach, though.

[shellscape]

@rubencodes even in that flip-the-switch scenario, there's a cert somewhere.

[joshwiens]

@rubencodes - One of the issues with auto-generated HTTPS certs comes into play when trying to connect to a backend via HTTPS ( You need the certs to match ) & auto-generated SSL certs across repos sounds tedious.

Add selfsigned lib

yarn add selfsigned --dev

Top level directory for certs

mkdir ./ssl

Add package.json script

"certs": "node ./.ssl/selfsigned",

Ignore generated certs in .gitignore

.ssl/*.crt
.ssl/*.key

Add ./ssl/selfsigned.js ( change the URI for your environment )

const fs = require('fs');
const selfsigned = require('selfsigned');
const attrs = [{ name: 'commonName', value: 'deviantjs.local' }];
const pems = selfsigned.generate(attrs, {
  algorithm: 'sha256',
  keySize: 2048,
  extensions: [
    {
      name: 'subjectAltName',
      altNames: [
        {
          type: 2, // DNS
          value: 'localhost',
        },
        {
          type: 2, // DNS
          value: 'deviantjs.local',
        },
        {
          type: 6, // URI
          value: 'https://deviantjs.local',
        },
        {
          type: 7, // IP
          ip: '127.0.0.1',
        },
      ],
    },
  ],
});

fs.writeFileSync('./.ssl/server.crt', pems.cert, { encoding: 'utf-8' });
fs.writeFileSync('./.ssl/server.key', pems.private, { encoding: 'utf-8' });

The following certs can then be used in any number of server side applications. The following only needs to be run once in local development.

I get what you are looking for but in the end, the flip the switch approach is limiting. You could just as easily execute the above as a post install script and get what is essentially the same thing with all the freedom you need in a more complicated development setup.

[davewasmer]

@d3viant0ne if I understand your post correctly, I think the biggest difference between devcert and selfsigned is that devcert generates trusted certificates. If you use selfsigned, then I imagined you'd see the browser warnings about untrusted / misconfigured SSL, and other tools may simply not work at all (i.e. curl).

[shellscape]

I'm adding documentation today to point users to devcert-cli, so we can safely close this one. That'll be the recommended course for users that want to test https locally.