41 ms·

It's perfectly normal to install new root certificates - for example, so that a company can sign internal websites (or for MITM proxies). It's incredibly shady

by zorked 8y ago

It's perfectly normal to install new root certificates - for example, so that a company can sign internal websites (or for MITM proxies). It's incredibly shady to have random software install into your trust store.

rblatz 8y ago
As someone that has been burned by self signed internal only sites. Take the extra 15 minutes and get a proper cert, and domain name for your internal sites. It can save a massive amount of pain later.
- zAy0LfpBZLC8mAC 8y ago
  burned how exactly?
  - hannasanarion 8y ago
    It can be a real pain in the butt to go up and down the whole stack and reconfigure every library and application that might detect a insecure connection and bail. Need several independent webapps to communicate? Hoo boy.
  - rblatz 8y ago
    In this case we started doing hybrid cloud, we were unable to address a ton of sites since they were on a made up internal only tld. Plus every thing we could address served up certs we couldn’t trust since we were utilizing services that didn’t allow us to modify the trusted root cert store. We saved probably $100 and 2 hours by rolling our own solutions instead of doing things the standard way. It took weeks to clean the mess completely up.
    - zAy0LfpBZLC8mAC 8y ago
      Well, yeah, using a made up domain is obviously a bad idea ... but what does that have to do with root CAs? And how does trusting your own root CA lead to not trusting the certs presented by other parties? I don't really understand what kind of scenario you are describing there. And no, I don't see anything "standard" about not running your own CA, it is perfectly standard as far as I am concerned, and a really good idea as well. Relying on an external CA for internal services just creates risks of both availability and security. If you need an external CA to set up or continue operating internal services, that is an availability risk, and if you trust the whole standard set of root CAs for all of your internal services, that's a massive security risk.
      - rblatz 8y ago
        Obviously if all your services are hosted in house and you will never need to expose internal services externally go for it. But as soon as your organization grows, splits, merges or starts utilizing other services that don’t give you access to the trust store you are boned. It screwed us, and was a giant pain to fix.
        zAy0LfpBZLC8mAC 8y ago
        Why would all your services have to be hosted in house and why would it prevent you from "exposing internal services" (I mean, apart from the fact that they kindof aren't internal services anymore from that point on)? For one, there is no problem hosting your own services elsewhere and having them use your own certificates. But more importantly: Why should your own CA prevent you from obtaining certificates from an external CA for external services? I mean, it just doesn't, that's how I run stuff: Purely internal stuff runs on internal CA, stuff that needs to face the public somehow runs on globally recognized CAs. And it's mostly trivial to switch services from one to the other - or to just run two endpoints, one using the internal CA, one using an external CA. It seems to me like your problem wasn't your own root CA, your problem was that your services were incompatible with external CAs for some reason, among them probably your private DNS root? But that isn't a reason why you should put your internal services at risk from mismanaged public CAs, that's simply a reason why you should use a global domain and support provisioning of certificates from external CAs.
        rblatz 8y ago
        The big issue was identifying all the impacted services, reconfiguring all of them testing and redeploying them. If it’s a few services fine. But once it’s a few hundred it’s a pain.
        zAy0LfpBZLC8mAC 8y ago
        Well ... but then that still has nothing to do with using your own root CA, does it? I mean, why would you want to suddenly reconfigure all of your services to use a different CA? It might come up here and there that you need external access to some service hat was internal before, but that is hardly a huge problem to reconfigure?! And also, if you have so many services running that swapping out all of the certificates is a major headache, your primary mistake probably was that that wasn't automated? When keys are compromised, you should be able to reprovision anyway.
- wil421 8y ago
  Why? It you are testing applications in a dev/test system that is only a available on the company VPN then how can you get burned? Sure it’s annoying clicking through browser warnings but if it’s not public facing I don’t see the danger.
  - rblatz 8y ago
    Just hope you never need an external system, or a cloud hosted service to talk to your dev/test environments. It’s so cheap and easy to do it right that it just doesn’t make sense to do it the other way.

by zorked 8y ago

rblatz 8y ago

As someone that has been burned by self signed internal only sites. Take the extra 15 minutes and get a proper cert, and domain name for your internal sites. It can save a massive amount of pain later.

zAy0LfpBZLC8mAC 8y ago
burned how exactly?
- hannasanarion 8y ago
  It can be a real pain in the butt to go up and down the whole stack and reconfigure every library and application that might detect a insecure connection and bail. Need several independent webapps to communicate? Hoo boy.
- rblatz 8y ago
  In this case we started doing hybrid cloud, we were unable to address a ton of sites since they were on a made up internal only tld. Plus every thing we could address served up certs we couldn’t trust since we were utilizing services that didn’t allow us to modify the trusted root cert store. We saved probably $100 and 2 hours by rolling our own solutions instead of doing things the standard way. It took weeks to clean the mess completely up.
  - zAy0LfpBZLC8mAC 8y ago
    Well, yeah, using a made up domain is obviously a bad idea ... but what does that have to do with root CAs? And how does trusting your own root CA lead to not trusting the certs presented by other parties? I don't really understand what kind of scenario you are describing there. And no, I don't see anything "standard" about not running your own CA, it is perfectly standard as far as I am concerned, and a really good idea as well. Relying on an external CA for internal services just creates risks of both availability and security. If you need an external CA to set up or continue operating internal services, that is an availability risk, and if you trust the whole standard set of root CAs for all of your internal services, that's a massive security risk.
    - rblatz 8y ago
      Obviously if all your services are hosted in house and you will never need to expose internal services externally go for it. But as soon as your organization grows, splits, merges or starts utilizing other services that don’t give you access to the trust store you are boned. It screwed us, and was a giant pain to fix.
      - zAy0LfpBZLC8mAC 8y ago
        Why would all your services have to be hosted in house and why would it prevent you from "exposing internal services" (I mean, apart from the fact that they kindof aren't internal services anymore from that point on)? For one, there is no problem hosting your own services elsewhere and having them use your own certificates. But more importantly: Why should your own CA prevent you from obtaining certificates from an external CA for external services? I mean, it just doesn't, that's how I run stuff: Purely internal stuff runs on internal CA, stuff that needs to face the public somehow runs on globally recognized CAs. And it's mostly trivial to switch services from one to the other - or to just run two endpoints, one using the internal CA, one using an external CA. It seems to me like your problem wasn't your own root CA, your problem was that your services were incompatible with external CAs for some reason, among them probably your private DNS root? But that isn't a reason why you should put your internal services at risk from mismanaged public CAs, that's simply a reason why you should use a global domain and support provisioning of certificates from external CAs.
        rblatz 8y ago
        The big issue was identifying all the impacted services, reconfiguring all of them testing and redeploying them. If it’s a few services fine. But once it’s a few hundred it’s a pain.
        zAy0LfpBZLC8mAC 8y ago
        Well ... but then that still has nothing to do with using your own root CA, does it? I mean, why would you want to suddenly reconfigure all of your services to use a different CA? It might come up here and there that you need external access to some service hat was internal before, but that is hardly a huge problem to reconfigure?! And also, if you have so many services running that swapping out all of the certificates is a major headache, your primary mistake probably was that that wasn't automated? When keys are compromised, you should be able to reprovision anyway.
wil421 8y ago
Why? It you are testing applications in a dev/test system that is only a available on the company VPN then how can you get burned? Sure it’s annoying clicking through browser warnings but if it’s not public facing I don’t see the danger.
- rblatz 8y ago
  Just hope you never need an external system, or a cloud hosted service to talk to your dev/test environments. It’s so cheap and easy to do it right that it just doesn’t make sense to do it the other way.