Should you use Let's Encrypt for internal hostnames?

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • puppeteer

    Node.js API for Chrome

    For any device that has a web interface, and no way of updating the cert automatically built in or via an API, you'd probably have to automate the process with something like puppeteer.

    https://www.npmjs.com/package/puppeteer

  • bulletproof-tls

    > By the way, EasyRSA still isn't that easy, but it's better than using OpenSSL directly.

    The trouble with EasyRSA (and similar tools) is that they make decisions for you and restrict what's possible and how. You're right about OpenSSL too, to use it directly requires a significant time investment to understand a lot about PKI.

    I tried to address this problem with documentation and templates. Here's a step by step guide for creating a private CA using OpenSSL, including intermediate certificates, revocation, and so on: https://www.feistyduck.com/library/openssl-cookbook/online/c... Every aspect is configurable, and here are the configuration templates: https://github.com/ivanr/bulletproof-tls/tree/master/private...

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • getssl

    obtain free SSL certificates from letsencrypt ACME server Suitable for automating the process on remote servers.

    > acme.sh

    Another shell-based ACME client I like is dehyradted. But for sending certs to remote systems from one central area, perhaps the shell-based GetSSL:

    > Obtain SSL certificates from the letsencrypt.org ACME server. Suitable for automating the process on remote servers.

    * https://github.com/srvrco/getssl

    In general, what you may want to do is configure Ansible/Puppet/etc, and have your ACME client drop the new cert in a particular area and have your configuration management system push things out from there.

  • acme.sh

    A pure Unix shell script implementing ACME client protocol

    > […] the public name record just has to exist.

    Specifically a TXT record for _acme-challenge has to exist for the requested hostname. Or a CNAME of the requested hostname pointing somewhere else that you control:

    * https://dan.langille.org/2019/02/01/acme-domain-alias-mode/

    * https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...

    * https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

    No A (or AAAA) records needed.

  • certificates

    🛡️ A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH.

    I'm biased because I'm the founder of the company, but you should check out the certificate management toolchain (CA[1] and CLI[2]) we've built at smallstep. A big focus of the project is human-friendliness. It's not perfect (yet) but I think we've made some good progress.

    We also have a hosted option[3] with a free tier that should work for individuals, homelabs, pre-production, and even small production environments. We've started building out a management UI there, and it does map to the CLI as you've described :).

    [1] https://github.com/smallstep/certificates

    [2] https://github.com/smallstep/cli

    [3] https://smallstep.com/certificate-manager/

  • cli

    🧰 A zero trust swiss army knife for working with X509, OAuth, JWT, OATH OTP, etc. (by smallstep)

    I'm biased because I'm the founder of the company, but you should check out the certificate management toolchain (CA[1] and CLI[2]) we've built at smallstep. A big focus of the project is human-friendliness. It's not perfect (yet) but I think we've made some good progress.

    We also have a hosted option[3] with a free tier that should work for individuals, homelabs, pre-production, and even small production environments. We've started building out a management UI there, and it does map to the CLI as you've described :).

    [1] https://github.com/smallstep/certificates

    [2] https://github.com/smallstep/cli

    [3] https://smallstep.com/certificate-manager/

  • boulder

    An ACME-based certificate authority, written in Go.

    GP's post prompted me to look into LE's ACME server implementation, Boulder [1], but it's pretty apparent that Boulder is not suitable for small scale deployments. But the smallstep "certificates" project seems to be a lot more reasonable for this use-case. Thanks for sharing, I'll definitely check it out!

    [1]: https://github.com/letsencrypt/boulder

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • proposals

    A home for well-formed proposed incubations for the web platform. All proposals welcome. (by WICG)

    I just finished writing a long proposal: https://github.com/WICG/proposals/issues/43

    PKI is fairly awful and bad for internal anything, unless you have a full IT team and infrastructure.

    A much simpler solution would be URLs with embedded public keys, with an optional discover and pair mechanism.

    Browsers already have managed profiles. Just set them up with a trusted set of "paired" servers and labels, push the configs with ansible(It's just like an old school hosts file!), and don't let them pair with anything new.

    If you have a small company of people you trust(probably a bad plan!), or are a home user, just use discovery. No more downloading an app to set up a smart device.

    The protocol as I sketched it out(and actually prototyped a version of) provides some extra layers of security, you can't connect unless you already know the URL, or discovery is on and you see it on the same LAN.

    We could finally stop talking to our routers and printers via plaintext on the LAN and encrypt everywhere.

    We already use exactly this kind of scheme to secure our keyboards and mice, with discovery in open air not even requiring being on the same LAN.

    We type our sensitive info into Google docs shared with an "anyone with this URL" feature.

    It seems we already trust opaque random URLs and pairing quite a bit. So why not trust them more than the terrible plaintext LAN services we use now?

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts