11 ms·

HTTPS is pain in the neck and _currently_ I hate it from the bottom of my heart. TLTR: if you have a commercial service or device running in a local network fo

by cryo 9y ago

HTTPS is pain in the neck and _currently_ I hate it from the bottom of my heart. TLTR: if you have a commercial service or device running in a local network forget HTTPS and service workers, use HTTP and HTML5 appcache. -- RANT starts here -- It would be lovely when every website and webapp uses HTTPS. But for a significant amount of them it's just not f..... possible without driving users completely insane. If the HTTPS server doesn't (and never will) have a public domain forget about encryption and security, forget about using service workers. The following examples can't, by the love of god, ever provide HTTPS without completely f..cking up user experience due self signed certificates warnings: 1) internal corporation services, websites and webapps. 2) services that run in a local private network like on a Raspberry Pi. 3) webapps which are served via public HTTPS website, but need to talk via CORS to local unsecured services, like to a Philips hue bridge, or any other IoT device which is in the local network but only provides HTTP. These will enlight the users with a shiny mixed-content warning. .... JUST use self-signed certificates, they said. NO. For normal users the UX of self-signed certificates is just non existent, it's a complete mess! It will scare the sh't out of users and will almost always look like your service is plain malware. It looks much more secure to serve a good'ol HTTP site with no encryption at all.

sgift 9y ago
> 1) internal corporation services, websites and webapps. For this use case companies usually provide an internal CA, which signs their certificates and is trusted by all company machines. We have various customers which do this and it works just fine.
- jakobbuis 9y ago
  This fails utterly when you can't control your clients. My student society for example ran into this problem. Students bring their own laptops and installing our root certificate on all of them is infeasible (if they even would allow us to do so). As a consequence, we need to expose critical internal services on the public internet, some of which contain private user data.
  - mrmondo 9y ago
    If you can’t control your clients - maybe use a captive portal style landing page with a link to install the local certificate or something along those lines, it’s also useful to have a wireless network (SSID/VLAN) for BYOD that just has internet access and as such doesn’t need the very and one that has access to internal services that does.
  - Dylan16807 9y ago
    If you let any student that brings their own laptop connect to it, then it's already pretty darn public. And you don't actually have to expose it to the internet to get a certificate, you only have to give it a public name.
    - Freak_NL 9y ago
      Additionally, if you let anyone bring their own device in a diverse semi-public environment like a school, you owe it to the students and faculty alike to provide them with some protection against creative types placing fake wifi access points in busy places, trying to play man-in-the-middle for any credentials and other stuff sent to your local services. HTTPS does that. Using a proper FQDN for each service only makes everything easier to maintain.
  - BillinghamJ 9y ago
    You don’t need to expose them. You need to use public DNS records, but there is no reason those records have to point to public IPs. e.g. my company uses *.int.cuvva.co which all point to IPs in the 10.0.0.0/8 block, but we still have HTTPS certificates for all of those.
  - will_hughes 9y ago
    > As a consequence, we need to expose critical internal services on the public internet, some of which contain private user data. No, you just need to have a public DNS entry, no need for that service to be reachable from the internet. foo.example.com can resolve to your private RFC1918 address, when you send the CSR to a CA, they'll verify your ownership of example.com.
  - 9y ago
- wfunction 9y ago
  And why would I trust a company I work at to be able to sign certificates for every single website on the internet? Especially if I need to install that root certificate on a personal device?
  - icebraining 9y ago
    Why would you need to install it in a personal device? Just add an exception. It's still better than plain HTTP since you can check the fingerprint against your work PC, which already validated the cert.
    - wfunction 9y ago
      Add an exception for every single internal site? You know how annoying that gets?
  - revelation 9y ago
    Because you already trust chinese, russian and a bunch of unethical for profit companies to do that?
    - wfunction 9y ago
      As a matter of fact I don't. I'm keeping track of my root certs.
  - dspillett 9y ago
    If you need such a device to do your job, maybe ask them to provide one so you can keep work off your personal device anyway? I disconnected my phone and so forth from work email and other services some time ago, and I'm not going back!
- 15thandwhatever 9y ago
  Large companies do this. Small companies/small groups of developers have no idea how to implement and manage this, but think that it should be easy. I've recently been approached by a group of developers to enable SSL on their internal sites. When I mentioned that this would take some time, the response was "why can't you just use LetsEncrypt?" I replied that LE only works on external facing sites, not internal sites. The next response was "fine, why don't we make it all external facing?" I'm still trying to explain that their CI server (Jenkins, with its history of remotely exploitable vulnerabilities), and their internal OAuth2 server should not be public facing.
  - Lazare 9y ago
    > I replied that LE only works on external facing sites, not internal sites. LE supports DNS validation; as far as I'm aware it now works great for internal sites.
    - mattowen_uk 9y ago
      Specifically... LetsEncrypt, and most other CAs no longer issue certs for domains that are not legal ccTLDs or gTLDs. Not so many years ago, Microsoft recommended that organisations used [companyname].local as their internal DNS zone[1], as .local will never be an external zone, so there would be no conflict. Then along came cloud integration and increased need for edge services, and .local no worked well as a solution. Servers needed certs with both the local domain and a new external domain in their certs which became a security nightmare. Then (about a year ago) CAs stopped issuing certs for domains that weren't sub-domains of proper TLDs, which all but killed the concept of these internal non-legal domains. So, unless you are prepared to roll your own CA, AND instruct your internal (non MS-domain members) users how to manually install an untrusted cert, signing internal sites that do not have a legal domain name, is a complete non-starter. --- [1] Now of course they recommend a sub-domain of your public domain name (site1.company.com), or a reserved public domain name that you don't use externally (site1-company.com). Which is all well and good, but what about the 100s of legacy kit you've got on the old name... ~sigh~
  - cm2187 9y ago
- ewanm89 9y ago
  I even do this on my own private network. Installing root certificates is not hard.
solatic 9y ago
If you're in a corporate intranet environment, you ought to have an intranet CA, as well as the means to distribute the CA's certificates securely to all deployed machines within the intranet.
- tempay 9y ago
  That's okay unless you allow users to bring there own devices, then you have users which are taught to bypass certificate errors on a daily basis.
  - bjpbakker 9y ago
    Sorry but I have to call BS on that. I always bring my own device and never have bypassed certificate errors. A company will either have certificates for their own apps (commonly running on specific subdomains of their own domain) or have their own internal CA that you can trust on your own device. Certificate errors on "internal" web apps are just as bad as on the rest of the internet.
    - wfunction 9y ago
      If you trust a company's internal CA then aren't you trusting them to issue certificates for every website and not just their own? Isn't that dangerous?
      - bjpbakker 9y ago
        Yes absolutely. If I have to I trust the company's CA in a special browser profile that I only use for working with their internal tools. For just a few tools it's often simpler to just trust those specific certificates, though
      - ewanm89 9y ago
        All browsers can tell you what certificate signed the one in use. Unfortunately a recent chrome UI change made this a pain to get to.in chrome, into the other browsers just clicking on the lock in the address bar, it soon becomes obvious if the company is mitm all SSL connections.
jcassee 9y ago
Would just creating (public) DNS records for those private addresses be a solution for 1 and 2?
JumpCrisscross 9y ago
FYI, I recently watched a potential portfolio company fail dilgence for having "insecure network practices". The diligence item? Is the lockbox green. Do I agree with this signal? Not entirely. But the company was forced into restart and into new management. Guess what colour their lockboxes were? The default has shifted; if your best retort is "it's hard," I'm not sure what to tell you. Yet government, maybe?
sschueller 9y ago
Yes. Also why do I get a certificate warning that looks the same for an IP (https://192.168.1.1 https://192.168.1.1) which you can not buy certificates? What about 10.x.x.x or even 127.0.0.1? As far as I know you can also no longer purchase a certificate for public IPs. Just watch how consumer router manufactures are going to work around this by either re-educating their users to ignore the red warnings or only selling cloud managed and locked devices which sucks for everyone.
- ewanm89 9y ago
  Assign a fqdn, I log into my router with a domain name, most routers actually have a domain name for them. Configure the LAN setting of RT-AC68U. Device Name: ghandi
bjpbakker 9y ago
> 1) internal corporation services, websites and webapps If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? And how would you feel if people on the same LAN could see and modify all your interactions with those services? 2) services that run in a local private network like on a Raspberry Pi Depending on the type of service you may or may not want TLS. If you visit the service by IP address and specific port anyway, you can easily add an exception for your internal IP. This will never be used like so by non-tech-savvy people. 3) webapps which are served via public HTTPS website, but need to talk via CORS to local unsecured services I cannot think of any reason to /not/ want to use HTTPS on this. It's horrible how things like the Philips Hue bridge work and rely on insecure HTTP to control your home lighting. Don't blame browsers for warning people for their insecure systems and appliances. Instead blame their creators or manufacturers as they're the ones who can fix this situation. edit: formatting
- cryo 9y ago
  > It's horrible how things like the Philips Hue bridge work and rely on insecure HTTP to control your home lighting. The Philips hue bridge REST API is accessible in the local network like http://192.168.1.123/api/ http://192.168.1.123/api/ .... which is great since apps/wepapps can talk to the bridge without a cloud or philips server inbetween. And this is the very problem, it's not possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server, keeping the very cool feature to talk only within the local network to the bridge. Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings?
  - bjpbakker 9y ago
    > it's not possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server I don't see why not. The alternative is freedom. Philips doesn't have to lock their devices. That's a choice they made, sadly the choice that most companies make. > Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings? The fact that your browser warns you about insecure communication happening from that web page, that's a good thing. Even iff you deliberately choose accept that and believe that there's no other way for this particular service/device. The simple fact that you accept some insecure traffic, doesn't make it secure.
Lazare 9y ago
> If the HTTPS server doesn't (and never will) have a public domain Then give it a public domain, keep it on a private network, and use a real certificate?
Sir_Substance 9y ago
>1) internal corporation services, websites and webapps. If this is an internal corporation service, why don't you bake your own self-signed root certificate into every computer in your network? Then you can generate as many certificates from your own root as you like, and they'll all magically be valid on corporate computers.
macns 9y ago
> It looks much more secure to serve a good'ol HTTP site with no encryption at all. Not for long it won't: Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS. Taken from Google security blog[1] back in Sept 2016: https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html https://security.googleblog.com/2016/09/moving-towards-more-...
NKCSS 9y ago
You can solve this with DNS if you'd want... Have every local machine get something that is internet-routable to a public machine that allows you to get a certificate, then on your corporate DNS, just serve the local machine it's supposed to go to and you can use that cert. You could use Let's Encrypt for this and have free certs.
- greggman 9y ago
  no, limit 5 certs per domain
  - NKCSS 9y ago
    You can get a SAN certificate where it has 100+ domains in 1 cert.
    - deadbunny 9y ago
      They'll also be providing wildcard certs soon.
  - deadbunny 9y ago
    Erm, no it isn't. https://community.letsencrypt.org/t/does-lets-encrypt-has-limitation-on-the-number-of-certificates-that-can-be-issued-for-one-server/23663 https://community.letsencrypt.org/t/does-lets-encrypt-has-li...
geogriffin 9y ago
Western Digital solves #2 and #3 for the MyCloud EX4 by somehow issuing real browser-trusted certs to each device for the domain device<mac_address>.wd2go.com using their intermediate CA "Western Digital Technologies Certification Authority" (https://www.censys.io/certificates/eb94f8e2c8d0c8338bb8ba40e1ead6224b842cbafc99f269eef0761e839c41a6 https://www.censys.io/certificates/eb94f8e2c8d0c8338bb8ba40e...), which is in turn issued by COMODO. Now, not everyone has an intermediate CA locked to their own domain, but maybe that's the issue? X.509 has the ability to restrict CAs to particular domains (e.g. see the "path constraint" on WD's CA in the info link above), so if it was easy to be issued a CA cert for your own domain, couldn't that be a potential solution to this problem?
ewanm89 9y ago
1) internal company webapps just install company root cert and create properly signed certs under corporate internal CA. Installing the certificate across network is easily automatable on windows, OSX and Linux. The only issue is Firefox as it uses its own trust store. Any senior admin who can't figure it out with the resources available (plenty of information available online) should be replaced days it is not that hard. 2) with regards to raspberry pi, will anyone who can write code can learn to also create their own CA the only difference is probably no automation of adding to the trust store likely however it is only a 2-3 click install in most cases.
- felipelemos 9y ago
  You are assuming that you control all client machines. Unfortunately it is not always possible and far from the admin technical decision. The admin usually can't fire the upper management.
  - deleted 9y ago
    [deleted]
  - skywhopper 9y ago
    It's possible to purchase certs signed by pre-trusted CAs extremely cheaply ($9/year/name) that can then be used on internal services. This is not a difficult problem to solve.
    - djrogers 9y ago
      Only if you also control DNS for those internal machines...
    - felipelemos 9y ago
      You can't buy certs for non.public.domain.local. So you must control the CA list at all client machines and use a self signed cert. The assumptions that there is a solution to the problem do not take in consideration that some times these changes are not possible. If I were to choose everyone would be using public domains with DNS zone view for public / private environments but Microsoft DNS service don't even support it.
jcrites 9y ago
> 1) internal corporation services, websites and webapps. That one's straightforward. Set up a corporate CA and use it for your internal certificates. Or, operate your corporate services on your real domain name, and use real publicly-trusted certificates - whichever is easier.
- Xcelerate 9y ago
  > Set up a corporate CA and use it for your internal certificates. Good luck with Docker containers running any Unix software that bundles the "default" root CAs along with it.
  - vetinari 9y ago
    Clients need the CA cert in their trust store, not servers. Client get it by the act of enrolling into AD or FreeIPA domain. On the docker side (or rather on the reverse proxy that provides access to them) you are solving different problem and it does not matter whether the key/cert is provided by your internal CA or third-party one.
  - ptman 9y ago
    Just build your own docker container based on the one you want. E.g.: FROM kanboard/kanboard:stable ADD ownca.crt /usr/local/share/ca-certificates/ownca.crt RUN /usr/sbin/update-ca-certificates
    - Xcelerate 9y ago
      The problem is you can't do this for every Docker image you have, particularly for a large organization. It defeats the whole point of having base images if you need "include" Dockerfiles. If Docker had a way to build from multiple base images, that might fix the issue, but I believe they removed that bug/feature a while back.
    - deleted 9y ago
      [deleted]
bryanlarsen 9y ago
You can get a certificate for a local IP address. If you own foo.com, you can get a cert for local.foo.com from letsencrypt that points to 192.168.1.5. Obviously you can't use HTTP verification, but you can use DNS verification, point _acme-challenge.local.foo.com to a public server and run certsling or another acme client on that server.
abrkn 9y ago
Just buy a .com domain for your internal service and serve DNS over VPN
raverbashing 9y ago
Self sign from an internal CA and add that to client keychains (but yeah your points are valid, which is deeply unfortunate)
xena 9y ago
let's encrypt is free, you have no excuse.
fundabulousrIII 9y ago
This is complete nonsense.
pampa 9y ago
> 1) internal corporation services, websites and webapps. When firefox started throwing warnings on my intranet sites that are accessed via OpenVPN i did this: 1) move all internal sites to valid FQDN 2) push dns settings over openvpn so that clients resolve the names with the internal dns service and dont leak names. Names withing the vpn resolve to internal ip addresses. 3) set up a catch-all website, point the wildcard *.company.name domain to it and mada letsencrypt certs for the internail domains/ 4) copy the valid certs to the intranet webserver. Done. Everything working ok.

by cryo 9y ago

sgift 9y ago

> 1) internal corporation services, websites and webapps. For this use case companies usually provide an internal CA, which signs their certificates and is trusted by all company machines. We have various customers which do this and it works just fine.

jakobbuis 9y ago
This fails utterly when you can't control your clients. My student society for example ran into this problem. Students bring their own laptops and installing our root certificate on all of them is infeasible (if they even would allow us to do so). As a consequence, we need to expose critical internal services on the public internet, some of which contain private user data.
- mrmondo 9y ago
  If you can’t control your clients - maybe use a captive portal style landing page with a link to install the local certificate or something along those lines, it’s also useful to have a wireless network (SSID/VLAN) for BYOD that just has internet access and as such doesn’t need the very and one that has access to internal services that does.
- Dylan16807 9y ago
  If you let any student that brings their own laptop connect to it, then it's already pretty darn public. And you don't actually have to expose it to the internet to get a certificate, you only have to give it a public name.
  - Freak_NL 9y ago
    Additionally, if you let anyone bring their own device in a diverse semi-public environment like a school, you owe it to the students and faculty alike to provide them with some protection against creative types placing fake wifi access points in busy places, trying to play man-in-the-middle for any credentials and other stuff sent to your local services. HTTPS does that. Using a proper FQDN for each service only makes everything easier to maintain.
- BillinghamJ 9y ago
  You don’t need to expose them. You need to use public DNS records, but there is no reason those records have to point to public IPs. e.g. my company uses *.int.cuvva.co which all point to IPs in the 10.0.0.0/8 block, but we still have HTTPS certificates for all of those.
- will_hughes 9y ago
  > As a consequence, we need to expose critical internal services on the public internet, some of which contain private user data. No, you just need to have a public DNS entry, no need for that service to be reachable from the internet. foo.example.com can resolve to your private RFC1918 address, when you send the CSR to a CA, they'll verify your ownership of example.com.
- 9y ago
wfunction 9y ago
And why would I trust a company I work at to be able to sign certificates for every single website on the internet? Especially if I need to install that root certificate on a personal device?
- icebraining 9y ago
  Why would you need to install it in a personal device? Just add an exception. It's still better than plain HTTP since you can check the fingerprint against your work PC, which already validated the cert.
  - wfunction 9y ago
    Add an exception for every single internal site? You know how annoying that gets?
- revelation 9y ago
  Because you already trust chinese, russian and a bunch of unethical for profit companies to do that?
  - wfunction 9y ago
    As a matter of fact I don't. I'm keeping track of my root certs.
- dspillett 9y ago
  If you need such a device to do your job, maybe ask them to provide one so you can keep work off your personal device anyway? I disconnected my phone and so forth from work email and other services some time ago, and I'm not going back!
15thandwhatever 9y ago
Large companies do this. Small companies/small groups of developers have no idea how to implement and manage this, but think that it should be easy. I've recently been approached by a group of developers to enable SSL on their internal sites. When I mentioned that this would take some time, the response was "why can't you just use LetsEncrypt?" I replied that LE only works on external facing sites, not internal sites. The next response was "fine, why don't we make it all external facing?" I'm still trying to explain that their CI server (Jenkins, with its history of remotely exploitable vulnerabilities), and their internal OAuth2 server should not be public facing.
- Lazare 9y ago
  > I replied that LE only works on external facing sites, not internal sites. LE supports DNS validation; as far as I'm aware it now works great for internal sites.
  - mattowen_uk 9y ago
    Specifically... LetsEncrypt, and most other CAs no longer issue certs for domains that are not legal ccTLDs or gTLDs. Not so many years ago, Microsoft recommended that organisations used [companyname].local as their internal DNS zone[1], as .local will never be an external zone, so there would be no conflict. Then along came cloud integration and increased need for edge services, and .local no worked well as a solution. Servers needed certs with both the local domain and a new external domain in their certs which became a security nightmare. Then (about a year ago) CAs stopped issuing certs for domains that weren't sub-domains of proper TLDs, which all but killed the concept of these internal non-legal domains. So, unless you are prepared to roll your own CA, AND instruct your internal (non MS-domain members) users how to manually install an untrusted cert, signing internal sites that do not have a legal domain name, is a complete non-starter. --- [1] Now of course they recommend a sub-domain of your public domain name (site1.company.com), or a reserved public domain name that you don't use externally (site1-company.com). Which is all well and good, but what about the 100s of legacy kit you've got on the old name... ~sigh~
- cm2187 9y ago
ewanm89 9y ago
I even do this on my own private network. Installing root certificates is not hard.

solatic 9y ago

If you're in a corporate intranet environment, you ought to have an intranet CA, as well as the means to distribute the CA's certificates securely to all deployed machines within the intranet.

tempay 9y ago
That's okay unless you allow users to bring there own devices, then you have users which are taught to bypass certificate errors on a daily basis.
- bjpbakker 9y ago
  Sorry but I have to call BS on that. I always bring my own device and never have bypassed certificate errors. A company will either have certificates for their own apps (commonly running on specific subdomains of their own domain) or have their own internal CA that you can trust on your own device. Certificate errors on "internal" web apps are just as bad as on the rest of the internet.
  - wfunction 9y ago
    If you trust a company's internal CA then aren't you trusting them to issue certificates for every website and not just their own? Isn't that dangerous?
    - bjpbakker 9y ago
      Yes absolutely. If I have to I trust the company's CA in a special browser profile that I only use for working with their internal tools. For just a few tools it's often simpler to just trust those specific certificates, though
    - ewanm89 9y ago
      All browsers can tell you what certificate signed the one in use. Unfortunately a recent chrome UI change made this a pain to get to.in chrome, into the other browsers just clicking on the lock in the address bar, it soon becomes obvious if the company is mitm all SSL connections.

jcassee 9y ago

Would just creating (public) DNS records for those private addresses be a solution for 1 and 2?

JumpCrisscross 9y ago

FYI, I recently watched a potential portfolio company fail dilgence for having "insecure network practices". The diligence item? Is the lockbox green. Do I agree with this signal? Not entirely. But the company was forced into restart and into new management. Guess what colour their lockboxes were? The default has shifted; if your best retort is "it's hard," I'm not sure what to tell you. Yet government, maybe?

sschueller 9y ago

Yes. Also why do I get a certificate warning that looks the same for an IP (https://192.168.1.1 https://192.168.1.1) which you can not buy certificates? What about 10.x.x.x or even 127.0.0.1? As far as I know you can also no longer purchase a certificate for public IPs. Just watch how consumer router manufactures are going to work around this by either re-educating their users to ignore the red warnings or only selling cloud managed and locked devices which sucks for everyone.

ewanm89 9y ago
Assign a fqdn, I log into my router with a domain name, most routers actually have a domain name for them. Configure the LAN setting of RT-AC68U. Device Name: ghandi

bjpbakker 9y ago

> 1) internal corporation services, websites and webapps If not for hostname validation, how would you even /know/ that you're talking to the "internal corporation service" rather than someones MITM proxy? And how would you feel if people on the same LAN could see and modify all your interactions with those services? 2) services that run in a local private network like on a Raspberry Pi Depending on the type of service you may or may not want TLS. If you visit the service by IP address and specific port anyway, you can easily add an exception for your internal IP. This will never be used like so by non-tech-savvy people. 3) webapps which are served via public HTTPS website, but need to talk via CORS to local unsecured services I cannot think of any reason to /not/ want to use HTTPS on this. It's horrible how things like the Philips Hue bridge work and rely on insecure HTTP to control your home lighting. Don't blame browsers for warning people for their insecure systems and appliances. Instead blame their creators or manufacturers as they're the ones who can fix this situation. edit: formatting

cryo 9y ago
> It's horrible how things like the Philips Hue bridge work and rely on insecure HTTP to control your home lighting. The Philips hue bridge REST API is accessible in the local network like http://192.168.1.123/api/ http://192.168.1.123/api/ .... which is great since apps/wepapps can talk to the bridge without a cloud or philips server inbetween. And this is the very problem, it's not possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server, keeping the very cool feature to talk only within the local network to the bridge. Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings?
- bjpbakker 9y ago
  > it's not possible for Philips to add HTTPS support to the hue bridge without some sort of cloud roundtrip to a Philips server I don't see why not. The alternative is freedom. Philips doesn't have to lock their devices. That's a choice they made, sadly the choice that most companies make. > Because how could that be deployed without self-signed certificates and the usual browser exceptions and warnings? The fact that your browser warns you about insecure communication happening from that web page, that's a good thing. Even iff you deliberately choose accept that and believe that there's no other way for this particular service/device. The simple fact that you accept some insecure traffic, doesn't make it secure.

Lazare 9y ago

> If the HTTPS server doesn't (and never will) have a public domain Then give it a public domain, keep it on a private network, and use a real certificate?

Sir_Substance 9y ago

>1) internal corporation services, websites and webapps. If this is an internal corporation service, why don't you bake your own self-signed root certificate into every computer in your network? Then you can generate as many certificates from your own root as you like, and they'll all magically be valid on corporate computers.

macns 9y ago

> It looks much more secure to serve a good'ol HTTP site with no encryption at all. Not for long it won't: Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS. Taken from Google security blog[1] back in Sept 2016: https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html https://security.googleblog.com/2016/09/moving-towards-more-...

NKCSS 9y ago

You can solve this with DNS if you'd want... Have every local machine get something that is internet-routable to a public machine that allows you to get a certificate, then on your corporate DNS, just serve the local machine it's supposed to go to and you can use that cert. You could use Let's Encrypt for this and have free certs.

greggman 9y ago
no, limit 5 certs per domain
- NKCSS 9y ago
  You can get a SAN certificate where it has 100+ domains in 1 cert.
  - deadbunny 9y ago
    They'll also be providing wildcard certs soon.
- deadbunny 9y ago
  Erm, no it isn't. https://community.letsencrypt.org/t/does-lets-encrypt-has-limitation-on-the-number-of-certificates-that-can-be-issued-for-one-server/23663 https://community.letsencrypt.org/t/does-lets-encrypt-has-li...

geogriffin 9y ago

Western Digital solves #2 and #3 for the MyCloud EX4 by somehow issuing real browser-trusted certs to each device for the domain device<mac_address>.wd2go.com using their intermediate CA "Western Digital Technologies Certification Authority" (https://www.censys.io/certificates/eb94f8e2c8d0c8338bb8ba40e1ead6224b842cbafc99f269eef0761e839c41a6 https://www.censys.io/certificates/eb94f8e2c8d0c8338bb8ba40e...), which is in turn issued by COMODO. Now, not everyone has an intermediate CA locked to their own domain, but maybe that's the issue? X.509 has the ability to restrict CAs to particular domains (e.g. see the "path constraint" on WD's CA in the info link above), so if it was easy to be issued a CA cert for your own domain, couldn't that be a potential solution to this problem?

ewanm89 9y ago

1) internal company webapps just install company root cert and create properly signed certs under corporate internal CA. Installing the certificate across network is easily automatable on windows, OSX and Linux. The only issue is Firefox as it uses its own trust store. Any senior admin who can't figure it out with the resources available (plenty of information available online) should be replaced days it is not that hard. 2) with regards to raspberry pi, will anyone who can write code can learn to also create their own CA the only difference is probably no automation of adding to the trust store likely however it is only a 2-3 click install in most cases.

felipelemos 9y ago
You are assuming that you control all client machines. Unfortunately it is not always possible and far from the admin technical decision. The admin usually can't fire the upper management.
- deleted 9y ago
  [deleted]
- skywhopper 9y ago
  It's possible to purchase certs signed by pre-trusted CAs extremely cheaply ($9/year/name) that can then be used on internal services. This is not a difficult problem to solve.
  - djrogers 9y ago
    Only if you also control DNS for those internal machines...
  - felipelemos 9y ago
    You can't buy certs for non.public.domain.local. So you must control the CA list at all client machines and use a self signed cert. The assumptions that there is a solution to the problem do not take in consideration that some times these changes are not possible. If I were to choose everyone would be using public domains with DNS zone view for public / private environments but Microsoft DNS service don't even support it.

jcrites 9y ago

> 1) internal corporation services, websites and webapps. That one's straightforward. Set up a corporate CA and use it for your internal certificates. Or, operate your corporate services on your real domain name, and use real publicly-trusted certificates - whichever is easier.

Xcelerate 9y ago
> Set up a corporate CA and use it for your internal certificates. Good luck with Docker containers running any Unix software that bundles the "default" root CAs along with it.
- vetinari 9y ago
  Clients need the CA cert in their trust store, not servers. Client get it by the act of enrolling into AD or FreeIPA domain. On the docker side (or rather on the reverse proxy that provides access to them) you are solving different problem and it does not matter whether the key/cert is provided by your internal CA or third-party one.
- ptman 9y ago
  Just build your own docker container based on the one you want. E.g.: FROM kanboard/kanboard:stable ADD ownca.crt /usr/local/share/ca-certificates/ownca.crt RUN /usr/sbin/update-ca-certificates
  - Xcelerate 9y ago
    The problem is you can't do this for every Docker image you have, particularly for a large organization. It defeats the whole point of having base images if you need "include" Dockerfiles. If Docker had a way to build from multiple base images, that might fix the issue, but I believe they removed that bug/feature a while back.
  - deleted 9y ago
    [deleted]

bryanlarsen 9y ago

You can get a certificate for a local IP address. If you own foo.com, you can get a cert for local.foo.com from letsencrypt that points to 192.168.1.5. Obviously you can't use HTTP verification, but you can use DNS verification, point _acme-challenge.local.foo.com to a public server and run certsling or another acme client on that server.

abrkn 9y ago

Just buy a .com domain for your internal service and serve DNS over VPN

raverbashing 9y ago

Self sign from an internal CA and add that to client keychains (but yeah your points are valid, which is deeply unfortunate)

xena 9y ago

let's encrypt is free, you have no excuse.

fundabulousrIII 9y ago

This is complete nonsense.

pampa 9y ago

> 1) internal corporation services, websites and webapps. When firefox started throwing warnings on my intranet sites that are accessed via OpenVPN i did this: 1) move all internal sites to valid FQDN 2) push dns settings over openvpn so that clients resolve the names with the internal dns service and dont leak names. Names withing the vpn resolve to internal ip addresses. 3) set up a catch-all website, point the wildcard *.company.name domain to it and mada letsencrypt certs for the internail domains/ 4) copy the valid certs to the intranet webserver. Done. Everything working ok.