33 ms·

Certificates for localhost

684 points by colinprince 8y ago

aequitas 8y ago
I've been using Terraform (https://www.terraform.io/docs/providers/tls/index.html https://www.terraform.io/docs/providers/tls/index.html) lately for local CA's like my homelab. It's nice when you want to keep everything in configuration management. Example of a self-signed CA: https://gitlab.com/failmap/ca/blob/master/ca.tf https://gitlab.com/failmap/ca/blob/master/ca.tf
zapdrive 8y ago
Easiest way is to get a certificate for a subdomain of a domain you own, e.g. dev.example.com, and then point dev.example.com to 127.0.0.1 in your hosts file.
- 456hdsaq234g 8y ago
  No, never do this. I will find your keys, and I will have your certificate revoked. *also misread, I was considering the DNS case. Lightly, dont do this for the hosts file example either.
- gruez 8y ago
  from TFA: >It’s possible to set up your own domain name that happens to resolve to 127.0.0.1, and get a certificate for it using the DNS challenge. However, this is generally a bad idea and there are better options.
  - Macha 8y ago
    I read that as being about the actual public DNS, not your own local hosts file?
    - vbezhenar 8y ago
      Malicious network could forge DNS responses and direct user into fake server. HTTPS should protect user, because face server can't own proper certificate for that domain. But if private key is leaked, this attack could work.
      - icebraining 8y ago
        There are no DNS responses if the domain is in the hosts file.
- philip1209 8y ago
  This sounds like a bad idea. You don't want private keys to a production subdomain being handed around teams. For instance, let's say you have dev.mybank.com. Somebody could trivially poison a DNS cache for a local system to redirect to their server, have a valid SSL key on the company domain, and implement a very real-looking phishing website for the company. Another problem - controlling a subdomain could be used to steal login cookies from the main website. This is why Github moved Github Pages to a separate domain: https://blog.github.com/2013-04-09-yummy-cookies-across-domains/ https://blog.github.com/2013-04-09-yummy-cookies-across-doma...
  - nikanj 8y ago
    A domain you own <-> a production domain. Our corp has corptech.com and a few similar ones for this purpose. A generic .com costs about nothing, so no point in running anything non-production on your primary domain.
- ezekg 8y ago
  Or use ngrok.io. :)
  - tootie 8y ago
    Ngrok will route all your traffic over the internet.
- shittyadmin 8y ago
  They discuss this in the article with some good criticisms of it. You could maybe try something with a fully different origin, like mysite-dev.com...
- hackerpacker 8y ago
  yup, works fine for a small trusted team or when you wear all the hats, also useful for troubleshooting occasionally.
- _sdegutis 8y ago
  From the article: > "You might be tempted to work around these limitations by setting up a domain name in the global DNS that happens to resolve to 127.0.0.1 (for instance, localhost.example.com), getting a certificate for that domain name, shipping that certificate and corresponding private key with your native app, and telling your web app to communicate with https://localhost.example.com:8000/ https://localhost.example.com:8000/ instead of http://127.0.0.1:8000/ http://127.0.0.1:8000/. Don’t do this. It will put your users at risk, and your certificate may get revoked." EDIT: oops, it's not exactly what you were talking about, since you suggested only pointing it to 127.0.0.1 in your own /etc/hosts file, so I don't think the article answers your idea directly
456hdsaq234g 8y ago
Ive found many of these, and reported them to the vendors. Sometimes they are happy (swag!!!), sometimes they are not. This is a great article that explains the issue and work arounds. Your friend is strings blah | grep PRIVATE KEY Run it over your fav bins today!
- schoen 8y ago
  Note that you can also report it to the issuing CA if the vendor doesn't take action, and the CA will revoke the certificate.
zaroth 8y ago
I’ve always liked the concept of a localhost’d web app talking back to a localhost web server. It seems like a great way to get the cross-platform ease of use of developing the UI without having to do everything in browser, so you can optimize the heavy lifting and don’t end up with an Electron app pulling 8Gb of RAM and 100% Of 16 cores. But I could never quite satisfy the nagging feeling that the localhost server could adequately be secured against outside network requests being routed to it, or as TFA mentions, inside network requests being routed away from it to an outsider! This article helped enumerate some of the difficulties of securing such a service. Things like a memory-safe parser, checking origins, etc. I wonder is there a definitive guide someone had setup, or even better a sample Golang or similar localhost server, which demonstrates the dozen-odd layers of checks and protections and magical incantations necessary to have such a server “secure” in the sense that a localhost UI is able to make requests to it to receive sensitive data but it should be safe from external attackers trying to spoof the same requests?
- zerkten 8y ago
  When I was working on e-detailing apps for pharmaceutical sales reps in 2007-2010 we did this. Originally the UI for was based on Flash and intended for Windows Tablet PC usage. I think the server security was pretty rudimentary.
- rcfox 8y ago
  > But I could never quite satisfy the nagging feeling that the localhost server could adequately be secured against outside network requests being routed to it, or as TFA mentions, inside network requests being routed away from it to an outsider! Wouldn't that be solved by binding your listener to 127.0.0.1 (as opposed to 0.0.0.0 or your actual IP)? Sending a request to 127.0.0.1 shouldn't be able to send anything to the network.
  - zaroth 8y ago
    But can’t any JavaScript in the browser can call back to 127.0.0.1 (within the bounds of cross-origin policy). So you have to check Origin/Referer at least I think. Can you be sure Origin/Referer isn’t spoofed? Then there’s DNS rebinding which can get around the SOP. What about maybe strange ways that malformed requests could end up being reflected back to 127.0.0.1 through rebinding? So it just seems to me that even binding to 127.0.0.1 you have to be ready for just about anything to come in on the socket.
BillinghamJ 8y ago
The Plex approach to this kind of problem is pretty interesting: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-... Unfortunately I haven't seen it being done elsewhere. It'd be nice if LetsEncrypt or similar could provide this for more generic everyday use.
- rogerbinns 8y ago
  I'm desperate for this. The hardware product I work on can be controlled by a mobile app. It was a very deliberate decision to not make the hardware product and mobile app both have to talk to a remote server acting as a proxy between the two. But that leaves me using plain http between the two.
  - pstuart 8y ago
    Couldn't you use it to coordinate NAT punchthrough?
    - rogerbinns 8y ago
      The mobile app (or web browser) are on the same network (subnet) as the hardware device. There is no need for NAT or anything else. Zeroconf is used for discovery. There is little threat in most home networks, but I still prefer using SSL. If we only had to support the mobile app then we could implement a solution (eg ssh style trust on first use with self signed certificates). However we also have to support regular browsers which constrains us to standard protocols and security.
      - mdtusz 8y ago
        I'm working on a product that has a similar case - we luckily have the benefit of the hardware having a display and input so that clients need to effectively pair themselves (i.e. you need to physically click an authorized button on the hardware) before they can have full access. We figure that if someone/something has access to the hardware, you're already boned.
jongalloway2 8y ago
If you're using ASP.NET Core, this is built into the most recent 2.1 release - local dev cert as well as HTTPS redirection middleware and HSTS in development. https://blogs.msdn.microsoft.com/webdev/2018/02/27/asp-net-core-2-1-https-improvements/ https://blogs.msdn.microsoft.com/webdev/2018/02/27/asp-net-c... https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-2.1&tabs=visual-studio https://docs.microsoft.com/en-us/aspnet/core/security/enforc... As the letsencrypt article points out, you want to start building and testing with HTTPS as early as possible, so this is all wired up as part of creating a new project with ASP.NET Core 2.1. [disclaimer: on .NET team, Nazgûl]
- ryanjshaw 8y ago
  Came here to write this, very impressed! Saved me so much time. It might help others to point out you need the ASP.NET Core 2.1.300 SDK -- 2.1.200 is not sufficient, and it took me a while to realise this. Perhaps I'm veering off topic, but why no Typescript in the 2.1 reactredux templates?
Grue3 8y ago
An absolute joke how many loops one needs to go through to do this very basic thing. Hell, this command line is longer than the code required to start a web server in some programming languages.
- tialaramex 8y ago
  To be fair, the complicated openssl invocation is largely because OpenSSL is crap. Let's break it down: "openssl req x509" This is a dodge because we don't actually want to write a CSR and then sign the cert, we're going to skip all that so we're using a sub-feature of a different sub-feature. Fine. "-out localhost.crt -keyout localhost.key" There surely must be nicer ways to set this, but it's not so objectionable... "-newkey rsa:2048" This is arguably boiler-plate, the configuration file can set this default, but there's a good chance "your" config file was pasted in by an OS vendor ten years ago and says e.g. 1024-bit RSA, or worse. "-nodes -sha256" Now we're getting into the nonsense. We don't want DES encryption. Nobody wants DES encryption, and if we did want DES encryption we could specify the passphrase for it, which we didn't, so this needn't be here. SHA-256 has been the reasonable baseline choice here for years and so likewise we shouldn't need to specify. "-subj '/CN=localhost'" This is pointlessly arcane and shouldn't be needed, but it's only partly OpenSSL's fault. This abuse of X.509 Common Name was obsolete on the Internet last century, and it's annoying the people were still coming to terms with that in the last few years so that certs which lack Common Name often don't interoperate, and thus it's easier to put it in anyway. "-extensions ...." This part, which involves a multi-line sub-shell and other shenanigans, is completely out of hand. This is the shortest, least crazy way to ask for the certificate practically everybody running OpenSSL actually wants, and yet instead of being the default or offered with some easy to understand command line parameter, even in brand new versions of OpenSSL it's done only by this arcane hack. All Web PKI certificates this century are supposed to use SANs (Subject Alternative Names), so you'd expect an openssl feature named say, "-san" which adds one such name, and OK, this being OpenSSL maybe you'd need to manually write "DNS:localhost" rather than it being smart enough to figure it out if you write "localhost". That'd be stupid, but par for OpenSSL. But no, you have to manually specify how SAN extensions even work in the X.509 certificate, as if it has never seen one before, even though every valid cert for the Web PKI has one. It's like if Firefox made you type not just the HTTP port default of 80 into URLs, but actually made you specify that you want to use TCP/IP in case maybe you're using Novell IPX or something.
rootusrootus 8y ago
I was hoping for a good answer, rather than "this is hard and it will just get worse." We have an old app that my team is modernizing with this exact situation. Uses websockets now, but that's an historical thing and all the web apps were non-secure so it worked okay. Now everyone wants SSL turned on, and this puts the websocket method in jeopardy. Somebody before me decided we should switch all the inter-app communication to an external XMPP server. Ugh.
- vbezhenar 8y ago
  Theoretically you should be able to use ws://127.0.0.1 from https context but I'm not aware if it's already well supported in the browsers.
- recursive 8y ago
  What's wrong with wss://?
  - rootusrootus 8y ago
    As a practical matter you cannot implement a localhost secure websocket. Essentially all of the methods for communicating between a web app and a native app are some kind of ugly hack and none are supported well enough that you can feel confident they'll stick around for any length of time in all the major browsers.
- anty 8y ago
  Same here. We use a subdomain with HTTPS that points to 127.0.0.1, and a WebSockets-Server on our clients machines. We install the private key on each machine for this to work... yeah. It's always a nightmare, when a browser-upgrade comes along and changes something. Currently the following connections work: "wss://localhost.example.com:4321/somepath", // Mac: Chrome, Safari, FF "wss://localhost:4321/somepath", // Win: Chrome, FF "wss://127.0.0.1:4320/somepath" // Win: EDGE, IE11, IE10 Some other combinations are possible, that's just what I know we use atm. The worst thing is: I didn't find a way to catch connection-errors to these URLs. So I have to use timeouts, and try all of them... (or decide by User-Agent which URLs to try.) I wish there would be some kind of standard that solves this problem.
thatha7777 8y ago
I suspect that the default reading of this text means "add your localhost.crt to the system's locally trusted roots" (or worse, "import the root certificate [to your locally trusted roots]"). Although there are methods to "install localhost.crt in your list of locally trusted roots" so that it's only visible to your application, I'm concerned about the naive reading of the post. I would be very concerned to find that a random application like Spotify, is installing root certificates on my machine, as that would allow them to MITM any connection that doesn't have some kind of key pinning. Although not exactly the same case, because the driver's shenanigans had no legitimate use, while Spotify does have a legitimate use, an audio driver caught installing a CA root certificate was reported as a CVE vulnerability: https://www.kb.cert.org/vuls/id/446847 https://www.kb.cert.org/vuls/id/446847
- vbezhenar 8y ago
  Blizzard application installs root certificate: https://news.ycombinator.com/item?id=15982161 https://news.ycombinator.com/item?id=15982161 I can say that I wasn't even aware about it, it installs absolutely silently. So if you care about it, check it from time to time, because that random application may install it at any time!
  - 0xCMP 8y ago
    It's not a root certificate in the CA sense. It can't sign new certificates and is only for the browser to communicate to the https server running on the same computer. The key isn't even distributed anywhere. It's generated locally and then marked trusted so the browsers don't show warnings. Checking the list of certificates from time to time is a good idea, although I wonder if anyone really does that very often without some automated help, but in this case Blizzard was doing something that was not only fine (using a self-signed cert to secure local traffic) but the absolutely correct way to do this. (As additionally explained by Let's Encrypt themselves) edit: I guess the one thing is: If you can find the certificate's private key you can serve your own server at that domain and launch an attack using a trusted certificate without needing admin permission to add your own malicious certificate.
vbezhenar 8y ago
There's government CA in Kazakhstan issuing certificates for people and for some government websites. They have software for people, so their website can talk to USB tokens. This website connects to that software via secure websockets at 127.0.0.1. And they bundle private key for 127.0.0.1 issued by that CA inside that application. Is it bad? I guess there's no point to report it to them, because they are CA and developers. It's not browser CA, it's some kind of "private" CA (users must import their certificate as a trusted root to work with their website and software).
- maxvu 8y ago
  I visited recently and was wondering what that was. https://imgur.com/a/F2iAMm7 https://imgur.com/a/F2iAMm7 Who uses these tokens, and what for?
  - vbezhenar 8y ago
    Ordinary people, for example I own one. It's a USB crypto device which stores private key and certificate. It handles all cryptographic operations inside, so private key can't be extracted (at least trivially). Actually most people use simple files, but it's significantly less secure, because file could be easily stolen. As to certificates, they are required for some internet services. There's portal http://egov.kz/cms/en http://egov.kz/cms/en which provides almost all government services for citizens and to use it, you should own certificate (so you sign your request with digital signature and it's treated by law like you signed it with your hand).
    - maxvu 8y ago
      Excellent, thank you!
- skim_milk 8y ago
  I worked for a place that did something similar, they were running a server on their local machines listening to https://localhost.company.com:someport https://localhost.company.com:someport (resolving to 127.0.0.1) so their javascript frontend hosted at example.com could communicate with their local machine. It was set up so the server would only respond to requests originating from company.com. They distributed the private key for the certificate localhost.company.com which was trusted by all browsers. What kind of risk is there to having the private key to localhost.company.com?
judge2020 8y ago
Relevant discussion regarding Activision/Blizzard's use of the domain "localbattle.net" (pointing to 127.0.0.1) for localhost communication with the agent: Reddit: https://www.reddit.com/r/heroesofthestorm/comments/7lb8vq/hey_blizzard_whats_the_deal_with_this_sneaky_root/ https://www.reddit.com/r/heroesofthestorm/comments/7lb8vq/he... Blizzard response: https://us.battle.net/forums/en/bnet/topic/20760626838 https://us.battle.net/forums/en/bnet/topic/20760626838
- rnotaro 8y ago
  It reminds me of that time when I accidentally went on a domain that had his A record set to 127.0.0.1. I was extremely confused about why a random domain had a copy of my project.
meagher 8y ago
wrote about how you can do this with a multi-container docker set up https://meagher.co/blog/2018/05/21/certificates-for-localhost/ https://meagher.co/blog/2018/05/21/certificates-for-localhos...
tootie 8y ago
I'm having a hard time understanding the use case here. Using a domain name for loopback IP and generating a cert will work fine for internal use. They're saying it's a security hole because you may need to distribute that private key to users. What exactly is that scenario? Shipping an app with a built-in web server? Not sure I've ever seen that done. And could you not solve it with certificate pinning?
- beokop 8y ago
  HTTP/2 requires https in most (all?) browsers these days. If you’re measuring load times locally this can be a bit of a problem.
  - deathanatos 8y ago
    Major browsers require TLS for HTTP/2. HTTP/2 requires no such thing, and the standard addresses how HTTP/2 should work on a unencrypted connection. (The connection starts as HTTP/1.1, and is upgraded to HTTP/2 with the Upgrade header.)
- kilburn 8y ago
  > What exactly is that scenario? Shipping an app with a built-in web server? I've had this need a couple times. My scenario: web-based application that needs to use some usb-gadget (NFC reader for example). You cannot access the device directly because there's no (standard) Browser <> NFC Reader API implemented in the browsers. You need native code to access that device. Yet your entire application is web-based, and it would be fine if only you could interface with that pesky gadget. In the past, people used NPAPI plugins for that, but those days are gone (browser plugins are much more sandboxed now, so they just don't have those capabilities anymore). Solution? You ship a companion small native app. That native app is supposed to interface your web application with the usb device. How do you achieve that? Simple, the native app exposes an http/websocket-based API at "localhost:someport" on the one side, and talks to the device using native drivers on the other. If you don't use https in your web-app, that is it. Your web-app can now communicate with your native app (by making requests to "localhost:someport"), and through your native app communicate with the device. Problem solved... right? Wrong, because your web application should be using https. For security reasons, the browser will _not_ allow connections from an https-page to a non-https (or secured web sockets) server. Thus, your native app's exposed API must use https/wss too. And here is where the article's ordeal begins. > And could you not solve it with certificate pinning? Pinning a certificate is not secure because using the same certificate in all installations is not secure: notice that your native app must have the certificate and the corresponding private key (because it must serve requests under that "localhost:port"). At this point, any of your users could just grab that cert/key pair (from their local installation) and use it to man-in-the-middle your other clients (the cert is valid for them too!). The problem is exactly the same if you obtain a publicly-recognized certificate and distributed it with your native app. The secure solution is, as the article says, to generate a certificate _specific for this user_ during the installation of your native app, and adding that certificate to the user's certificate store. This way the certificate is only valid for that user. Your native app can use this user-specific certificate to serve https/wss requests, and the user's browser will connect to that without warnings because the certificate is trusted. However, if user A extracts the certificate and key from her installation and tries to use them to main-in-the-middle another user B, it won't work because the certificate B trusts is his own installation-time-generated-one, not A's certificate which is different.
nailer 8y ago
Browsers are solving this by making localhost trusted over http (so webcam, notifications, and other privileged features work work), but here's a more specific guide to getting localhost https working on MacOS - using Keychain and a single command to export the created cert into PEM for your local webserver: https://certsimple.com/blog/localhost-ssl-fix https://certsimple.com/blog/localhost-ssl-fix
justinclift 8y ago
> Traffic sent to 127.0.0.1 is guaranteed not to leave your machine. ... Isn't that a widely held, but incorrect, assumption? eg People with reasonable knowledge of IPv4 on *nix can still route 127.0.0.1 traffic out through an external interface? From memory, people used to do that when attempting to bypass various firewall/filter rules on other hosts for a locally attached network. Maybe things have tightened up/changed in the last few years?
- phlo 8y ago
  No, 127.0.0.1 should never appear on any network, and no network device should ever route it. The earliest documentation I was able to find is in RFC 1122 [1] from 1989, but according to RFC 6890 [2], the principle dates back to 1981. [1] https://tools.ietf.org/html/rfc1122#section-3.2.1.3 https://tools.ietf.org/html/rfc1122#section-3.2.1.3 [2] https://tools.ietf.org/html/rfc6890 https://tools.ietf.org/html/rfc6890 (table 4)
  - justinclift 8y ago
    Ahhh yeah. But that's how most OS's set things up by default, in order to meet the required specs. (bugs and implementations hiccups aside) Once the OS is up and running, manipulation of the routing tables at least _used_ to make this possible on Linux and Solaris. Not sure about FreeBSD, but that's just from memory fuzziness on my part. :)
    - yebyen 8y ago
      > Traffic sent to 127.0.0.1 is guaranteed not to leave your machine This is definitely false, without any routing tables. Any unprivileged user can start an SSH tunnel listening on any localhost port above 1024, sending traffic out to wherever.
      - j4cob 8y ago
        The implicit threat model here is "no one outside your machine can do something to you to make 127.0.0.1 traffic route elsewhere." It's true that software running on your machine can make copies of things and send them elsewhere, but that's not the point of the sentence you quoted.
xg15 8y ago
What I don't understand is this bit: > Fortunately, modern browsers consider “http://127.0.0.1:8000/" http://127.0.0.1:8000/" to be a “potentially trustworthy” URL . [...] WebSockets don’t get this treatment for either name. It's good they at least added an exception for (verifyable) localhost access - but then why is the exception only given for HTTP? There seems to be a deliberate restriction that websockets are excluded. I find this kind of strange and frustrating as the websockets wire protocal actually contains more protections against accessing vulnerable services than HTTP. So without this exception, this leaves you no way at all to connect to a local service via websockets. I've found this ticket for chome[1] where apparently the rationale is that they want to move people to their own IPC messaging mechanism. However, this is chome only and requires you to register a chrome extension. So if I get this right, this still leaves no standard way to have asynchronous communication with a local process. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=418482 https://bugs.chromium.org/p/chromium/issues/detail?id=418482
- jadbox 8y ago
  While a huge pain the ass, it could be possible for your local app server to create a [bridged] virtual host network that routes locally for your server. It utterly ridiculous to resort to this method though. Does anyone else have an idea of a workaround?
  - xg15 8y ago
    That wouldn't solve the problem though. The browser would still block your bridged connection if it isn't https or wss. At which point you again need a domain for your virtual IP, a certificate for your domain and a private key for the certificate on the device, which will probably cause your certificate to be reported as a vulnerability and revoked.
- cjm 8y ago
  Chrome permits access to ws://127.0.0.1 from https apps. I believe it's also making its way to Firefox, which is currently http only. Other browsers (ie/edge/safari) don't even follow this exception for http yet.
2332434343 8y ago
wow.check out this cool blog http://mawazo.tk http://mawazo.tk
wildpeaks 8y ago
Good timing, I was working on a short tutorial on how to setup HTTPS for localhost, including how to get a green lock even in Chrome 58+: https://gist.github.com/cecilemuller/9492b848eb8fe46d462abeb26656c4f8 https://gist.github.com/cecilemuller/9492b848eb8fe46d462abeb...
654564560 8y ago
wow.checkout this cool forum http://mawazo.tk http://mawazo.tk
ctcherry 8y ago
https://github.com/ctcherry/tlself https://github.com/ctcherry/tlself I created this proxy to help with this, it dynamically creates certs from a self-signed-trusted local CA. It only targets OSX for now. It's not perfect but it has been working great for me.
metafunctor 8y ago
The openssl command in the article is great, but I might add "-days 3650" or something so I don't need to re-generate the certificate every month. Also, I wouldn't use the host name "localhost", but something like "mydomain.test", and update /etc/hosts accordingly.
beagle3 8y ago
Everyone here and TFA talk about 127.0.0.1 (a.k.a localhost), but the entire 127.0.0.0/8 subnet is routed to the local machine - does anyone here know how the browsers treat the other addresses? Do they compare to 127.0.0.1? to 127.0.0.0/8? Do they consult the routing table?
Myrmornis 8y ago
Is it time to start using a better acronym than either XHR or AJAX? Is there a modern accurate alternative for an HTTP request made by a browser that is not a request for a page reload?
- dfcowell 8y ago
  I believe the term you're looking for is a fetch (from the fetch API)? Though I don't know if that is also commonly used to refer to a standard page reload.
cedricziel 8y ago
We're using LetsEncrypt with local domains. We have a domain for internal usage only, where we can modify TXT records. Through this, and a little help from acme.sh, and dnsmasq, every workstation can have unlimited, valid certificates for local projects.
- chillydawg 8y ago
  Are you using a fake domain or a real one? If fake, I'd be interested in how that works.
  - cedricziel 8y ago
    Real domain, just no A record. For our projects, we create domains like {project}.{workstation}.company.net
    - mdtusz 8y ago
      Any chance there's a write-up or docs on this somewhere?
endzeit 8y ago
I've posted a RFC about a potential service/solution for this 3 days ago on the LE community boards: https://community.letsencrypt.org/t/rfc-a-way-to-use-valid-https-with-local-hosts/64596/13 https://community.letsencrypt.org/t/rfc-a-way-to-use-valid-h... The idea is to basically offer a free subdomain service (ssl.fun) in conjunction with solving the DNS-01 challenge. This would automate the existing practice of using a e.g. a public local.domain.com A record pointing to 127.0.0.1 The difference in this approach in regards to previous attempts is that the private key would not be compromised, as the client is issuing it directly. Happy to receive feedback on this idea :-) As this would run into the 20 certs-per-domain LE limit quickly it needs some blessing before I can offer this service publicly.
captn3m0 8y ago
I run my local apache server with a wildcard certificate for *.captnemo.in. Works perfectly. I forward `$port.in.captnemo.in` -> localhost:$port via Apache for some common ports and can access all my local servers easily over HTTPS. I can expose some specific service by changing the DNS to my local WLAN ip address (have a script for this that updates the DNS entry in cloudflare).
michaelmior 8y ago
> This subtly changes how browsers handle cookie storage. Good article, although would have been nice to have an explanation on this final point.
tempodox 8y ago
The command shown doesn't work on macOS. All I get is a usage text for openssl(1).
j4cob 8y ago
Folks may also be interested to read this useful summary of issues around locally installed roots: https://github.com/njh/dymo-root-ca-security-risk/blob/master/README.md#how-could-this-be-done-better https://github.com/njh/dymo-root-ca-security-risk/blob/maste...
homakov 8y ago
If you're desperate, just serve local sdk from http://localhost/sdk.html http://localhost/sdk.html which will talk to your local app via postMessage proxy. You may even open this proxy with window.open under https:// https:// app

684 points by colinprince 8y ago

I've been using Terraform (https://www.terraform.io/docs/providers/tls/index.html https://www.terraform.io/docs/providers/tls/index.html) lately for local CA's like my homelab. It's nice when you want to keep everything in configuration management. Example of a self-signed CA: https://gitlab.com/failmap/ca/blob/master/ca.tf https://gitlab.com/failmap/ca/blob/master/ca.tf

zapdrive 8y ago

Easiest way is to get a certificate for a subdomain of a domain you own, e.g. dev.example.com, and then point dev.example.com to 127.0.0.1 in your hosts file.

456hdsaq234g 8y ago
No, never do this. I will find your keys, and I will have your certificate revoked. *also misread, I was considering the DNS case. Lightly, dont do this for the hosts file example either.
gruez 8y ago
from TFA: >It’s possible to set up your own domain name that happens to resolve to 127.0.0.1, and get a certificate for it using the DNS challenge. However, this is generally a bad idea and there are better options.
- Macha 8y ago
  I read that as being about the actual public DNS, not your own local hosts file?
  - vbezhenar 8y ago
    Malicious network could forge DNS responses and direct user into fake server. HTTPS should protect user, because face server can't own proper certificate for that domain. But if private key is leaked, this attack could work.
    - icebraining 8y ago
      There are no DNS responses if the domain is in the hosts file.
philip1209 8y ago
This sounds like a bad idea. You don't want private keys to a production subdomain being handed around teams. For instance, let's say you have dev.mybank.com. Somebody could trivially poison a DNS cache for a local system to redirect to their server, have a valid SSL key on the company domain, and implement a very real-looking phishing website for the company. Another problem - controlling a subdomain could be used to steal login cookies from the main website. This is why Github moved Github Pages to a separate domain: https://blog.github.com/2013-04-09-yummy-cookies-across-domains/ https://blog.github.com/2013-04-09-yummy-cookies-across-doma...
- nikanj 8y ago
  A domain you own <-> a production domain. Our corp has corptech.com and a few similar ones for this purpose. A generic .com costs about nothing, so no point in running anything non-production on your primary domain.
ezekg 8y ago
Or use ngrok.io. :)
- tootie 8y ago
  Ngrok will route all your traffic over the internet.
shittyadmin 8y ago
They discuss this in the article with some good criticisms of it. You could maybe try something with a fully different origin, like mysite-dev.com...
hackerpacker 8y ago
yup, works fine for a small trusted team or when you wear all the hats, also useful for troubleshooting occasionally.
_sdegutis 8y ago
From the article: > "You might be tempted to work around these limitations by setting up a domain name in the global DNS that happens to resolve to 127.0.0.1 (for instance, localhost.example.com), getting a certificate for that domain name, shipping that certificate and corresponding private key with your native app, and telling your web app to communicate with https://localhost.example.com:8000/ https://localhost.example.com:8000/ instead of http://127.0.0.1:8000/ http://127.0.0.1:8000/. Don’t do this. It will put your users at risk, and your certificate may get revoked." EDIT: oops, it's not exactly what you were talking about, since you suggested only pointing it to 127.0.0.1 in your own /etc/hosts file, so I don't think the article answers your idea directly

456hdsaq234g 8y ago

Ive found many of these, and reported them to the vendors. Sometimes they are happy (swag!!!), sometimes they are not. This is a great article that explains the issue and work arounds. Your friend is strings blah | grep PRIVATE KEY Run it over your fav bins today!

schoen 8y ago
Note that you can also report it to the issuing CA if the vendor doesn't take action, and the CA will revoke the certificate.

zaroth 8y ago

I’ve always liked the concept of a localhost’d web app talking back to a localhost web server. It seems like a great way to get the cross-platform ease of use of developing the UI without having to do everything in browser, so you can optimize the heavy lifting and don’t end up with an Electron app pulling 8Gb of RAM and 100% Of 16 cores. But I could never quite satisfy the nagging feeling that the localhost server could adequately be secured against outside network requests being routed to it, or as TFA mentions, inside network requests being routed away from it to an outsider! This article helped enumerate some of the difficulties of securing such a service. Things like a memory-safe parser, checking origins, etc. I wonder is there a definitive guide someone had setup, or even better a sample Golang or similar localhost server, which demonstrates the dozen-odd layers of checks and protections and magical incantations necessary to have such a server “secure” in the sense that a localhost UI is able to make requests to it to receive sensitive data but it should be safe from external attackers trying to spoof the same requests?

zerkten 8y ago
When I was working on e-detailing apps for pharmaceutical sales reps in 2007-2010 we did this. Originally the UI for was based on Flash and intended for Windows Tablet PC usage. I think the server security was pretty rudimentary.
rcfox 8y ago
> But I could never quite satisfy the nagging feeling that the localhost server could adequately be secured against outside network requests being routed to it, or as TFA mentions, inside network requests being routed away from it to an outsider! Wouldn't that be solved by binding your listener to 127.0.0.1 (as opposed to 0.0.0.0 or your actual IP)? Sending a request to 127.0.0.1 shouldn't be able to send anything to the network.
- zaroth 8y ago
  But can’t any JavaScript in the browser can call back to 127.0.0.1 (within the bounds of cross-origin policy). So you have to check Origin/Referer at least I think. Can you be sure Origin/Referer isn’t spoofed? Then there’s DNS rebinding which can get around the SOP. What about maybe strange ways that malformed requests could end up being reflected back to 127.0.0.1 through rebinding? So it just seems to me that even binding to 127.0.0.1 you have to be ready for just about anything to come in on the socket.

BillinghamJ 8y ago

The Plex approach to this kind of problem is pretty interesting: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-... Unfortunately I haven't seen it being done elsewhere. It'd be nice if LetsEncrypt or similar could provide this for more generic everyday use.

rogerbinns 8y ago
I'm desperate for this. The hardware product I work on can be controlled by a mobile app. It was a very deliberate decision to not make the hardware product and mobile app both have to talk to a remote server acting as a proxy between the two. But that leaves me using plain http between the two.
- pstuart 8y ago
  Couldn't you use it to coordinate NAT punchthrough?
  - rogerbinns 8y ago
    The mobile app (or web browser) are on the same network (subnet) as the hardware device. There is no need for NAT or anything else. Zeroconf is used for discovery. There is little threat in most home networks, but I still prefer using SSL. If we only had to support the mobile app then we could implement a solution (eg ssh style trust on first use with self signed certificates). However we also have to support regular browsers which constrains us to standard protocols and security.
    - mdtusz 8y ago
      I'm working on a product that has a similar case - we luckily have the benefit of the hardware having a display and input so that clients need to effectively pair themselves (i.e. you need to physically click an authorized button on the hardware) before they can have full access. We figure that if someone/something has access to the hardware, you're already boned.

jongalloway2 8y ago

If you're using ASP.NET Core, this is built into the most recent 2.1 release - local dev cert as well as HTTPS redirection middleware and HSTS in development. https://blogs.msdn.microsoft.com/webdev/2018/02/27/asp-net-core-2-1-https-improvements/ https://blogs.msdn.microsoft.com/webdev/2018/02/27/asp-net-c... https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-2.1&tabs=visual-studio https://docs.microsoft.com/en-us/aspnet/core/security/enforc... As the letsencrypt article points out, you want to start building and testing with HTTPS as early as possible, so this is all wired up as part of creating a new project with ASP.NET Core 2.1. [disclaimer: on .NET team, Nazgûl]

ryanjshaw 8y ago
Came here to write this, very impressed! Saved me so much time. It might help others to point out you need the ASP.NET Core 2.1.300 SDK -- 2.1.200 is not sufficient, and it took me a while to realise this. Perhaps I'm veering off topic, but why no Typescript in the 2.1 reactredux templates?

Grue3 8y ago

An absolute joke how many loops one needs to go through to do this very basic thing. Hell, this command line is longer than the code required to start a web server in some programming languages.

tialaramex 8y ago
To be fair, the complicated openssl invocation is largely because OpenSSL is crap. Let's break it down: "openssl req x509" This is a dodge because we don't actually want to write a CSR and then sign the cert, we're going to skip all that so we're using a sub-feature of a different sub-feature. Fine. "-out localhost.crt -keyout localhost.key" There surely must be nicer ways to set this, but it's not so objectionable... "-newkey rsa:2048" This is arguably boiler-plate, the configuration file can set this default, but there's a good chance "your" config file was pasted in by an OS vendor ten years ago and says e.g. 1024-bit RSA, or worse. "-nodes -sha256" Now we're getting into the nonsense. We don't want DES encryption. Nobody wants DES encryption, and if we did want DES encryption we could specify the passphrase for it, which we didn't, so this needn't be here. SHA-256 has been the reasonable baseline choice here for years and so likewise we shouldn't need to specify. "-subj '/CN=localhost'" This is pointlessly arcane and shouldn't be needed, but it's only partly OpenSSL's fault. This abuse of X.509 Common Name was obsolete on the Internet last century, and it's annoying the people were still coming to terms with that in the last few years so that certs which lack Common Name often don't interoperate, and thus it's easier to put it in anyway. "-extensions ...." This part, which involves a multi-line sub-shell and other shenanigans, is completely out of hand. This is the shortest, least crazy way to ask for the certificate practically everybody running OpenSSL actually wants, and yet instead of being the default or offered with some easy to understand command line parameter, even in brand new versions of OpenSSL it's done only by this arcane hack. All Web PKI certificates this century are supposed to use SANs (Subject Alternative Names), so you'd expect an openssl feature named say, "-san" which adds one such name, and OK, this being OpenSSL maybe you'd need to manually write "DNS:localhost" rather than it being smart enough to figure it out if you write "localhost". That'd be stupid, but par for OpenSSL. But no, you have to manually specify how SAN extensions even work in the X.509 certificate, as if it has never seen one before, even though every valid cert for the Web PKI has one. It's like if Firefox made you type not just the HTTP port default of 80 into URLs, but actually made you specify that you want to use TCP/IP in case maybe you're using Novell IPX or something.

rootusrootus 8y ago

I was hoping for a good answer, rather than "this is hard and it will just get worse." We have an old app that my team is modernizing with this exact situation. Uses websockets now, but that's an historical thing and all the web apps were non-secure so it worked okay. Now everyone wants SSL turned on, and this puts the websocket method in jeopardy. Somebody before me decided we should switch all the inter-app communication to an external XMPP server. Ugh.

vbezhenar 8y ago
Theoretically you should be able to use ws://127.0.0.1 from https context but I'm not aware if it's already well supported in the browsers.
recursive 8y ago
What's wrong with wss://?
- rootusrootus 8y ago
  As a practical matter you cannot implement a localhost secure websocket. Essentially all of the methods for communicating between a web app and a native app are some kind of ugly hack and none are supported well enough that you can feel confident they'll stick around for any length of time in all the major browsers.
anty 8y ago
Same here. We use a subdomain with HTTPS that points to 127.0.0.1, and a WebSockets-Server on our clients machines. We install the private key on each machine for this to work... yeah. It's always a nightmare, when a browser-upgrade comes along and changes something. Currently the following connections work: "wss://localhost.example.com:4321/somepath", // Mac: Chrome, Safari, FF "wss://localhost:4321/somepath", // Win: Chrome, FF "wss://127.0.0.1:4320/somepath" // Win: EDGE, IE11, IE10 Some other combinations are possible, that's just what I know we use atm. The worst thing is: I didn't find a way to catch connection-errors to these URLs. So I have to use timeouts, and try all of them... (or decide by User-Agent which URLs to try.) I wish there would be some kind of standard that solves this problem.

thatha7777 8y ago

I suspect that the default reading of this text means "add your localhost.crt to the system's locally trusted roots" (or worse, "import the root certificate [to your locally trusted roots]"). Although there are methods to "install localhost.crt in your list of locally trusted roots" so that it's only visible to your application, I'm concerned about the naive reading of the post. I would be very concerned to find that a random application like Spotify, is installing root certificates on my machine, as that would allow them to MITM any connection that doesn't have some kind of key pinning. Although not exactly the same case, because the driver's shenanigans had no legitimate use, while Spotify does have a legitimate use, an audio driver caught installing a CA root certificate was reported as a CVE vulnerability: https://www.kb.cert.org/vuls/id/446847 https://www.kb.cert.org/vuls/id/446847

vbezhenar 8y ago
Blizzard application installs root certificate: https://news.ycombinator.com/item?id=15982161 https://news.ycombinator.com/item?id=15982161 I can say that I wasn't even aware about it, it installs absolutely silently. So if you care about it, check it from time to time, because that random application may install it at any time!
- 0xCMP 8y ago
  It's not a root certificate in the CA sense. It can't sign new certificates and is only for the browser to communicate to the https server running on the same computer. The key isn't even distributed anywhere. It's generated locally and then marked trusted so the browsers don't show warnings. Checking the list of certificates from time to time is a good idea, although I wonder if anyone really does that very often without some automated help, but in this case Blizzard was doing something that was not only fine (using a self-signed cert to secure local traffic) but the absolutely correct way to do this. (As additionally explained by Let's Encrypt themselves) edit: I guess the one thing is: If you can find the certificate's private key you can serve your own server at that domain and launch an attack using a trusted certificate without needing admin permission to add your own malicious certificate.

vbezhenar 8y ago

There's government CA in Kazakhstan issuing certificates for people and for some government websites. They have software for people, so their website can talk to USB tokens. This website connects to that software via secure websockets at 127.0.0.1. And they bundle private key for 127.0.0.1 issued by that CA inside that application. Is it bad? I guess there's no point to report it to them, because they are CA and developers. It's not browser CA, it's some kind of "private" CA (users must import their certificate as a trusted root to work with their website and software).

maxvu 8y ago
I visited recently and was wondering what that was. https://imgur.com/a/F2iAMm7 https://imgur.com/a/F2iAMm7 Who uses these tokens, and what for?
- vbezhenar 8y ago
  Ordinary people, for example I own one. It's a USB crypto device which stores private key and certificate. It handles all cryptographic operations inside, so private key can't be extracted (at least trivially). Actually most people use simple files, but it's significantly less secure, because file could be easily stolen. As to certificates, they are required for some internet services. There's portal http://egov.kz/cms/en http://egov.kz/cms/en which provides almost all government services for citizens and to use it, you should own certificate (so you sign your request with digital signature and it's treated by law like you signed it with your hand).
  - maxvu 8y ago
    Excellent, thank you!
skim_milk 8y ago
I worked for a place that did something similar, they were running a server on their local machines listening to https://localhost.company.com:someport https://localhost.company.com:someport (resolving to 127.0.0.1) so their javascript frontend hosted at example.com could communicate with their local machine. It was set up so the server would only respond to requests originating from company.com. They distributed the private key for the certificate localhost.company.com which was trusted by all browsers. What kind of risk is there to having the private key to localhost.company.com?

judge2020 8y ago

Relevant discussion regarding Activision/Blizzard's use of the domain "localbattle.net" (pointing to 127.0.0.1) for localhost communication with the agent: Reddit: https://www.reddit.com/r/heroesofthestorm/comments/7lb8vq/hey_blizzard_whats_the_deal_with_this_sneaky_root/ https://www.reddit.com/r/heroesofthestorm/comments/7lb8vq/he... Blizzard response: https://us.battle.net/forums/en/bnet/topic/20760626838 https://us.battle.net/forums/en/bnet/topic/20760626838

rnotaro 8y ago
It reminds me of that time when I accidentally went on a domain that had his A record set to 127.0.0.1. I was extremely confused about why a random domain had a copy of my project.

meagher 8y ago

wrote about how you can do this with a multi-container docker set up https://meagher.co/blog/2018/05/21/certificates-for-localhost/ https://meagher.co/blog/2018/05/21/certificates-for-localhos...

tootie 8y ago

I'm having a hard time understanding the use case here. Using a domain name for loopback IP and generating a cert will work fine for internal use. They're saying it's a security hole because you may need to distribute that private key to users. What exactly is that scenario? Shipping an app with a built-in web server? Not sure I've ever seen that done. And could you not solve it with certificate pinning?

beokop 8y ago
HTTP/2 requires https in most (all?) browsers these days. If you’re measuring load times locally this can be a bit of a problem.
- deathanatos 8y ago
  Major browsers require TLS for HTTP/2. HTTP/2 requires no such thing, and the standard addresses how HTTP/2 should work on a unencrypted connection. (The connection starts as HTTP/1.1, and is upgraded to HTTP/2 with the Upgrade header.)
kilburn 8y ago
> What exactly is that scenario? Shipping an app with a built-in web server? I've had this need a couple times. My scenario: web-based application that needs to use some usb-gadget (NFC reader for example). You cannot access the device directly because there's no (standard) Browser <> NFC Reader API implemented in the browsers. You need native code to access that device. Yet your entire application is web-based, and it would be fine if only you could interface with that pesky gadget. In the past, people used NPAPI plugins for that, but those days are gone (browser plugins are much more sandboxed now, so they just don't have those capabilities anymore). Solution? You ship a companion small native app. That native app is supposed to interface your web application with the usb device. How do you achieve that? Simple, the native app exposes an http/websocket-based API at "localhost:someport" on the one side, and talks to the device using native drivers on the other. If you don't use https in your web-app, that is it. Your web-app can now communicate with your native app (by making requests to "localhost:someport"), and through your native app communicate with the device. Problem solved... right? Wrong, because your web application should be using https. For security reasons, the browser will _not_ allow connections from an https-page to a non-https (or secured web sockets) server. Thus, your native app's exposed API must use https/wss too. And here is where the article's ordeal begins. > And could you not solve it with certificate pinning? Pinning a certificate is not secure because using the same certificate in all installations is not secure: notice that your native app must have the certificate and the corresponding private key (because it must serve requests under that "localhost:port"). At this point, any of your users could just grab that cert/key pair (from their local installation) and use it to man-in-the-middle your other clients (the cert is valid for them too!). The problem is exactly the same if you obtain a publicly-recognized certificate and distributed it with your native app. The secure solution is, as the article says, to generate a certificate _specific for this user_ during the installation of your native app, and adding that certificate to the user's certificate store. This way the certificate is only valid for that user. Your native app can use this user-specific certificate to serve https/wss requests, and the user's browser will connect to that without warnings because the certificate is trusted. However, if user A extracts the certificate and key from her installation and tries to use them to main-in-the-middle another user B, it won't work because the certificate B trusts is his own installation-time-generated-one, not A's certificate which is different.

nailer 8y ago

Browsers are solving this by making localhost trusted over http (so webcam, notifications, and other privileged features work work), but here's a more specific guide to getting localhost https working on MacOS - using Keychain and a single command to export the created cert into PEM for your local webserver: https://certsimple.com/blog/localhost-ssl-fix https://certsimple.com/blog/localhost-ssl-fix

justinclift 8y ago

> Traffic sent to 127.0.0.1 is guaranteed not to leave your machine. ... Isn't that a widely held, but incorrect, assumption? eg People with reasonable knowledge of IPv4 on *nix can still route 127.0.0.1 traffic out through an external interface? From memory, people used to do that when attempting to bypass various firewall/filter rules on other hosts for a locally attached network. Maybe things have tightened up/changed in the last few years?

phlo 8y ago
No, 127.0.0.1 should never appear on any network, and no network device should ever route it. The earliest documentation I was able to find is in RFC 1122 [1] from 1989, but according to RFC 6890 [2], the principle dates back to 1981. [1] https://tools.ietf.org/html/rfc1122#section-3.2.1.3 https://tools.ietf.org/html/rfc1122#section-3.2.1.3 [2] https://tools.ietf.org/html/rfc6890 https://tools.ietf.org/html/rfc6890 (table 4)
- justinclift 8y ago
  Ahhh yeah. But that's how most OS's set things up by default, in order to meet the required specs. (bugs and implementations hiccups aside) Once the OS is up and running, manipulation of the routing tables at least _used_ to make this possible on Linux and Solaris. Not sure about FreeBSD, but that's just from memory fuzziness on my part. :)
  - yebyen 8y ago
    > Traffic sent to 127.0.0.1 is guaranteed not to leave your machine This is definitely false, without any routing tables. Any unprivileged user can start an SSH tunnel listening on any localhost port above 1024, sending traffic out to wherever.
    - j4cob 8y ago
      The implicit threat model here is "no one outside your machine can do something to you to make 127.0.0.1 traffic route elsewhere." It's true that software running on your machine can make copies of things and send them elsewhere, but that's not the point of the sentence you quoted.

xg15 8y ago

What I don't understand is this bit: > Fortunately, modern browsers consider “http://127.0.0.1:8000/" http://127.0.0.1:8000/" to be a “potentially trustworthy” URL . [...] WebSockets don’t get this treatment for either name. It's good they at least added an exception for (verifyable) localhost access - but then why is the exception only given for HTTP? There seems to be a deliberate restriction that websockets are excluded. I find this kind of strange and frustrating as the websockets wire protocal actually contains more protections against accessing vulnerable services than HTTP. So without this exception, this leaves you no way at all to connect to a local service via websockets. I've found this ticket for chome[1] where apparently the rationale is that they want to move people to their own IPC messaging mechanism. However, this is chome only and requires you to register a chrome extension. So if I get this right, this still leaves no standard way to have asynchronous communication with a local process. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=418482 https://bugs.chromium.org/p/chromium/issues/detail?id=418482

jadbox 8y ago
While a huge pain the ass, it could be possible for your local app server to create a [bridged] virtual host network that routes locally for your server. It utterly ridiculous to resort to this method though. Does anyone else have an idea of a workaround?
- xg15 8y ago
  That wouldn't solve the problem though. The browser would still block your bridged connection if it isn't https or wss. At which point you again need a domain for your virtual IP, a certificate for your domain and a private key for the certificate on the device, which will probably cause your certificate to be reported as a vulnerability and revoked.
cjm 8y ago
Chrome permits access to ws://127.0.0.1 from https apps. I believe it's also making its way to Firefox, which is currently http only. Other browsers (ie/edge/safari) don't even follow this exception for http yet.

2332434343 8y ago

wow.check out this cool blog http://mawazo.tk http://mawazo.tk

wildpeaks 8y ago

Good timing, I was working on a short tutorial on how to setup HTTPS for localhost, including how to get a green lock even in Chrome 58+: https://gist.github.com/cecilemuller/9492b848eb8fe46d462abeb26656c4f8 https://gist.github.com/cecilemuller/9492b848eb8fe46d462abeb...

654564560 8y ago

wow.checkout this cool forum http://mawazo.tk http://mawazo.tk

ctcherry 8y ago

https://github.com/ctcherry/tlself https://github.com/ctcherry/tlself I created this proxy to help with this, it dynamically creates certs from a self-signed-trusted local CA. It only targets OSX for now. It's not perfect but it has been working great for me.

metafunctor 8y ago

The openssl command in the article is great, but I might add "-days 3650" or something so I don't need to re-generate the certificate every month. Also, I wouldn't use the host name "localhost", but something like "mydomain.test", and update /etc/hosts accordingly.

beagle3 8y ago

Everyone here and TFA talk about 127.0.0.1 (a.k.a localhost), but the entire 127.0.0.0/8 subnet is routed to the local machine - does anyone here know how the browsers treat the other addresses? Do they compare to 127.0.0.1? to 127.0.0.0/8? Do they consult the routing table?

Myrmornis 8y ago

Is it time to start using a better acronym than either XHR or AJAX? Is there a modern accurate alternative for an HTTP request made by a browser that is not a request for a page reload?

dfcowell 8y ago
I believe the term you're looking for is a fetch (from the fetch API)? Though I don't know if that is also commonly used to refer to a standard page reload.

cedricziel 8y ago

We're using LetsEncrypt with local domains. We have a domain for internal usage only, where we can modify TXT records. Through this, and a little help from acme.sh, and dnsmasq, every workstation can have unlimited, valid certificates for local projects.

chillydawg 8y ago
Are you using a fake domain or a real one? If fake, I'd be interested in how that works.
- cedricziel 8y ago
  Real domain, just no A record. For our projects, we create domains like {project}.{workstation}.company.net
  - mdtusz 8y ago
    Any chance there's a write-up or docs on this somewhere?

endzeit 8y ago

I've posted a RFC about a potential service/solution for this 3 days ago on the LE community boards: https://community.letsencrypt.org/t/rfc-a-way-to-use-valid-https-with-local-hosts/64596/13 https://community.letsencrypt.org/t/rfc-a-way-to-use-valid-h... The idea is to basically offer a free subdomain service (ssl.fun) in conjunction with solving the DNS-01 challenge. This would automate the existing practice of using a e.g. a public local.domain.com A record pointing to 127.0.0.1 The difference in this approach in regards to previous attempts is that the private key would not be compromised, as the client is issuing it directly. Happy to receive feedback on this idea :-) As this would run into the 20 certs-per-domain LE limit quickly it needs some blessing before I can offer this service publicly.

captn3m0 8y ago

I run my local apache server with a wildcard certificate for *.captnemo.in. Works perfectly. I forward `$port.in.captnemo.in` -> localhost:$port via Apache for some common ports and can access all my local servers easily over HTTPS. I can expose some specific service by changing the DNS to my local WLAN ip address (have a script for this that updates the DNS entry in cloudflare).

michaelmior 8y ago

> This subtly changes how browsers handle cookie storage. Good article, although would have been nice to have an explanation on this final point.

tempodox 8y ago

The command shown doesn't work on macOS. All I get is a usage text for openssl(1).

j4cob 8y ago

Folks may also be interested to read this useful summary of issues around locally installed roots: https://github.com/njh/dymo-root-ca-security-risk/blob/master/README.md#how-could-this-be-done-better https://github.com/njh/dymo-root-ca-security-risk/blob/maste...

homakov 8y ago

If you're desperate, just serve local sdk from http://localhost/sdk.html http://localhost/sdk.html which will talk to your local app via postMessage proxy. You may even open this proxy with window.open under https:// https:// app