[HN Gopher] Mkcert: Simple zero-config tool to make locally trus...
       ___________________________________________________________________
        
       Mkcert: Simple zero-config tool to make locally trusted development
       certificates
        
       Author : thunderbong
       Score  : 192 points
       Date   : 2022-10-29 11:30 UTC (2 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | ddoolin wrote:
       | I just found this last week when setting up some local network
       | server bits and it was just perfect. Thank you!
        
       | PaulBGD_ wrote:
       | We use this with vite-plugin-mkcert to provide https localdev
       | with just the installation of mkcert from homebrew. Wayyyy
       | simpler than any other method of providing localdev https.
        
       | FiloSottile wrote:
       | _o/ author here! mkcert is definitely my most popular tool, and
       | it's always a delight to see how it makes developers' lives
       | easier and how happy they are about it <3
       | 
       | Something that I wonder about from time to time is how "done" is
       | mkcert. A lot of its value is in simplicity, so I've rejected
       | attempts to make it more of a toolkit to generate all sorts of
       | certificates (although I see the value in being able to edit the
       | expiration and other fields). The only thing on my TODO is
       | splitting the trust stores out into an importable package for
       | other tools to use. Maybe that will act as a release valve for
       | other use cases.
       | 
       | In a sense, mkcert will never be done because its job is also to
       | keep up with browser requirements for you, but that goes in
       | waves, and not much has changed in the last couple years. (Unlike
       | the first years of mkcert, when things were really a moving
       | target.) Similarly, it has to keep up with new trust stores and
       | ways to install into them, and we might be overdue for a pass of
       | that, but these are not really new features, just maintenance.
       | 
       | Previously:
       | 
       |  _Mkcert: Tool for making locally-trusted development
       | certificates_ -- https://news.ycombinator.com/item?id=17748208 --
       | Aug 2018 (39 comments)
       | 
       |  _Show HN: Mkcert - Valid HTTPS certificates for localhost_ --
       | https://news.ycombinator.com/item?id=18842218 -- Jan 2019 (118
       | comments)
        
         | codegeek wrote:
         | Thanks you for making it and keeping it simple. I agree that
         | the simplicity is what makes it great to use for localhost
         | testing. Big fan of this tool since I found it.
        
         | lifepillar wrote:
         | Thanks for this tool! I found it when Apple started enforcing
         | stricter requirements for certificates, and the commands I was
         | using to create certificates at the time had become inadequate.
         | I have since used mkcert to generate dozen of certificates for
         | my local network, which work on any service and device.
         | 
         | The only drawback of mkcert is that it makes you forget the
         | steps needed to make a certificate!
        
         | jzelinskie wrote:
         | No matter what I work on and how complex, mkcert is always
         | there for my dev environment. In combination with cert-
         | manager's CA support[0], even TLS for Kubernetes development
         | environments is simple as it gets.
         | 
         | Thanks Filippo!
         | 
         | [0]: https://cert-manager.io/docs/configuration/ca/
        
       | dainiusse wrote:
       | This should be part of openssl :)
        
       | philkuz wrote:
       | We use it at Pixie to easily setup certs for our self hosted
       | users. Amazing tool.
        
       | dang wrote:
       | Related:
       | 
       |  _Serve your local website on HTTPS with mkcert_ -
       | https://news.ycombinator.com/item?id=23653455 - June 2020 (1
       | comment)
       | 
       |  _Show HN: Mkcert - Valid HTTPS certificates for localhost_ -
       | https://news.ycombinator.com/item?id=18842218 - Jan 2019 (115
       | comments)
       | 
       |  _Mkcert: Tool for making locally-trusted development
       | certificates_ - https://news.ycombinator.com/item?id=17748208 -
       | Aug 2018 (38 comments)
        
       | nezirus wrote:
       | For local (GUI!) tools I find XCA (https://hohnstaedt.de/xca/)
       | excellent. It has a few ready to fo templates out of the box, and
       | you can make your own.
        
         | KronisLV wrote:
         | Personally, I've also had decent experiences with Keystore
         | Explorer: https://keystore-explorer.org/
         | 
         | I actually wrote about using it on my blog, which has plenty of
         | screenshots: https://blog.kronis.dev/tutorials/lets-run-our-
         | own-ca
         | 
         | It's pretty good for having your own simple CA, self signed
         | certificates or anything of the sort, as well as having a nicer
         | interface for anything that's not one of the ACME providers
         | (e.g. Let's Encrypt) or when you don't need CLI or automation.
        
       | pastage wrote:
       | Support for npm, python, emacs, cygwin would be nice. Better yet
       | run away if someone suggests a custom CA, it is not worth it.
        
       | justin_oaks wrote:
       | This says it's not meant for production use.
       | 
       | Does anyone know of something that is meant for production use
       | for generating in-house certificate authorities and signing
       | certificates?
       | 
       | I've used scripts I've written myself that run OpenSSL commands.
       | They get the job done, but they're not the kind of thing that
       | fits all use cases, and they're not user-friendly.
       | 
       | I've tried EasyRSA which is not particularly easy either. It
       | requires some unexpected use of environment variables, and I
       | didn't find the documentation very clear either.
        
         | NovemberWhiskey wrote:
         | Hashicorp Vault is an obvious one. Microsoft Active Directory
         | Certificate Service is another.
         | 
         | If you're looking for a service-oriented offering, maybe think
         | about Keyfactor, Venafi ... do you already have a PKI that you
         | need to integrate with, etc?
        
         | rad_gruchalski wrote:
         | cfssl is what I use, usually a root + intermedia ca, and leaf
         | certs, works really well with cert manager in kubernetes.
         | 
         | https://github.com/cloudflare/cfssl
        
         | groffee wrote:
         | Let's Encrypt? https://letsencrypt.org/
        
           | justin_oaks wrote:
           | Using an external service as a way of setting up internal-
           | only certificates? No thanks.
        
             | hisnameishank wrote:
             | It's not hard to make a CA.
             | 
             | Make a key for your CA, make an SSL key for your sever,
             | sign the key with your CA and add the CA to your in-house
             | browser/list of trusted CAs.
        
             | tialaramex wrote:
             | Intuitively this seems reasonable, but, as a sense check I
             | want to put the other side: Not necessarily with the goal
             | that you change your mind, but that you didn't end up just
             | doing what was intuitive without weighing the options.
             | 
             | The public CAs are run pretty well, and they have people
             | actually overseeing them to verify that remains so, without
             | you lifting a finger (well, unless you'd like to help
             | oversee them at least). In contrast a local CA is very
             | likely to be poorly run, because it's not really anybody's
             | actual job to do it properly, you can't justify the expense
             | [If you're Google, then, sure, you can justify the expense
             | but also you are not asking about this on HN] to train
             | them, they can't afford the time and effort to do their
             | best work.
             | 
             | The public CAs are almost certainly not going to lose their
             | root private key, if bad guys _do_ steal the root key for a
             | CA, it 'll make news and also you almost certainly aren't
             | the target, in contrast the root key for your private CA
             | probably lives on somebody's laptop (which can be left on a
             | train) or a server somewhere.
             | 
             | There's good tooling for the public CAs. Your software
             | might already come ready to use ACME, and if it doesn't you
             | will find instructions pretty easily. In contrast although
             | there are technology stacks for this stuff without the
             | public CA context, they're not as widespread, particularly
             | in Free Software, and you may find if you need certs for
             | five systems that means five separate tools. Or you do it
             | manually which sucks.
             | 
             | Everything already trusts the public CAs. It's not
             | difficult to tell Mac OS, Windows or even a Linux distro to
             | trust some root CA, but it's an extra step to be done and
             | if you forget it may be difficult to figure out why things
             | don't work. For some services that's enough, but if you
             | also want BYO devices to work that's a nightmare, likewise
             | for guest devices.
             | 
             | Names will almost certainly leak anyway. If your goal is to
             | hide the fact secret-project.example.com exists, I
             | _strongly_ recommend instead changing it to some-
             | codename.example.com so that you needn 't care much if the
             | name leaks.
             | 
             | None of the above makes _mkcert_ a bad idea - mkcert is for
             | development. But you should weigh this when deciding
             | whether internal-git-server.mycorp.example should just use
             | Let 's Encrypt certificates rather than spinning up an
             | internal only CA.
        
               | [deleted]
        
         | adrienthebo wrote:
         | I've had my eye on
         | [step](https://github.com/smallstep/certificates) and [step-
         | ca](https://github.com/smallstep/certificates) for a hot
         | minute; it's production quality and seems much more pleasant
         | than the EasyRSA scripts. Haven't tested it but I'd recommend
         | that as a place to start tinkering.
        
         | sreevisakh wrote:
         | You could use XCA [1] for small scale deployments, or step-ca
         | [2] for a more comprehensive setup.
         | 
         | [1] https://www.hohnstaedt.de/xca/
         | 
         | [2] https://smallstep.com/docs/step-ca
        
         | [deleted]
        
       | CSDude wrote:
       | We use it at our company. Also in CI. Because it's much more
       | straightforward and everyone can understand what it does. Glad it
       | exists.
        
       | hk1337 wrote:
       | Is this really needed for the "localhost" name? I understand the
       | need for this because a lot of people create multiple local
       | services with specific names other than localhost, so it would be
       | flagged as not being secure?
        
         | codegeek wrote:
         | It has use cases for localhost. For example, testing Secure
         | Cookies locally that can only be transmitted over https.
        
       | generalizations wrote:
       | Dumb question alert; can these certs be repurposed to sign
       | windows binaries for running locally?
       | 
       | Depending on the environment, windows can be set to prohibit
       | executing anything that isn't signed....which is annoying on a
       | dev machine building windows executables.
        
         | jackewiehose wrote:
         | > windows can be set to prohibit executing [...] on a dev
         | machine building windows executables
         | 
         | lol @ "dev machine" ?!
        
       | chrsig wrote:
       | seriously useful tool, i've never had setting up locally trusted
       | certs be any easier.
        
       | samgranieri wrote:
       | I really enjoy this tool making it easier, combined with dnsmasq
       | and nginx, to spin things up in whatever custom local tld I want
       | with a secure and trusted development certificate
        
       | azornathogron wrote:
       | I've used this in the past and it has been very convenient!
       | Thanks Filippo!
       | 
       | Having said that, nowadays I just bring up a local caddy instance
       | and use that. Caddy can set up and use a local CA for
       | development/testing [1]. In my case I'm using caddy on my little
       | public-facing hobby server anyway, so it's convenient to have a
       | similar setup in local dev. If I cared about actually getting at
       | & directly using the certificates myself I'd probably go back to
       | mkcert.
       | 
       | [1] https://caddyserver.com/docs/automatic-https#local-https
        
       ___________________________________________________________________
       (page generated 2022-10-31 23:00 UTC)