6 ms·

> 1) internal corporation services, websites and webapps. For this use case companies usually provide an internal CA, which signs their certificates and is tru

by 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.
- cm2187 9y ago
  A public domain name costs the price of a coffee (and less than a raspberry pi) and you can get a certificate for free with Let's Encrypt. There is really no reason to resort to a private CA unless you want to MITM your client's connection. You don't need to expose your server to the public internet to use let's encrypt. I use DNS authorization and it works perfectly.
- wfunction 9y ago
  > My student society for example > need to expose critical internal services on the public internet, some of which contain private user data. The heck? Are they aware of this? Might you get sued for this?
  - deleted 9y ago
    [deleted]
- kpcyrd 9y ago
  Even if you could I would highly recommend against doing that, given that this would grant you access to every https connection that isn't hpkp secured. I actually have all webservices in my home network secured by https, all you need to do is click a cheap vps, install nginx and tinc, and then proxy /.well-known/acme-challenge/ to your internal servers. Either setup domain or ip hijacking so the public IP is routed inside your lan. Done. If I can do this for me and my cat in my spare time, you can do this for your university.
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.

by sgift 9y ago

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.
cm2187 9y ago
A public domain name costs the price of a coffee (and less than a raspberry pi) and you can get a certificate for free with Let's Encrypt. There is really no reason to resort to a private CA unless you want to MITM your client's connection. You don't need to expose your server to the public internet to use let's encrypt. I use DNS authorization and it works perfectly.
wfunction 9y ago
> My student society for example > need to expose critical internal services on the public internet, some of which contain private user data. The heck? Are they aware of this? Might you get sued for this?
- deleted 9y ago
  [deleted]
kpcyrd 9y ago
Even if you could I would highly recommend against doing that, given that this would grant you access to every https connection that isn't hpkp secured. I actually have all webservices in my home network secured by https, all you need to do is click a cheap vps, install nginx and tinc, and then proxy /.well-known/acme-challenge/ to your internal servers. Either setup domain or ip hijacking so the public IP is routed inside your lan. Done. If I can do this for me and my cat in my spare time, you can do this for your university.

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.