SSL For Intranet Applications Deployed at Multiple Companies

问题

I have node application that serves over https. The app is served over the intranet. I remember generating the SSL key on the Linux command line and they've expired.

I have aspirations of installing this app at multiple companies. It will run on each company's intranet yet I do want the application to be accessible remotely (by setting up some port forwarders on the corporate firewall).

The SSL keys are pain. I want the communication to be encrypted, but because I'm generating the SSL keys myself, the user has to proceed past some scary browser warnings before they can begin using the app.

If I want these warning to go away, will I have to buy a separate SSL key for each intranet the app runs on in order to prevent the user from ever seeing these warnings? Can I make the expiration of these keys year 3000 (so they never practically expire)? I like https, but I despise paying money for official keys. Here's why:

With self generated keys, the encryption of the communication is just as secure as a purchased key. Yet, the browser makes the user think he's going to get a virus if he accepts my generated certificate. The browser treats everything like online banking, when sometimes you have other reason for encryption. Ok, enough complaining.

If you have an app that is primarily an intranet app, but do want to allow remote access, and the app is going to be installed at numerous companies, and you want the app to run over HTTPS, how can you lesson the burden of SSL key management?

The encryption isn't as important as online banking, but I want to have it. So, ideally, I want one a key I can generate myself (to avoid fees), or maybe one key I purchase, but I want that key to practically never expire, and I want it to serve multiple installations (at different companies) for my app. I'd like the key to not care about domain names. I want encrypted communication, but verification that I am who I say I am is not important to me at all.

How can I deploy an app like this in manner that will avoid browser warnings?

Please advise.

回答1:

I already posted an answer on your other question, but I see a number of misconceptions here that I considered worth addressing.

I have aspirations of installing this app at multiple companies. It will run on each company's intranet yet I do want the application to be accessible remotely (by setting up some port forwarders on the corporate firewall).

Note that security-wise this is practically identical to just running your application on the internet. Trying to rely on your application being hidden on some non-standard port is known as "security through obscurity", and it is a false sense of security.

If I want these warning to go away, will I have to buy a separate SSL key for each intranet the app runs on in order to prevent the user from ever seeing these warnings?

You'll need a certificate for your application, and you need visitors to trust your certificate. You can do this in two ways:

Obtain certificates from a CA, which are trusted out of the box.
Make your own certificates, and distribute them
- Manually
- Automated through some centralized means

These options are answered in more detail in your other question.

Can I make the expiration of these keys year 3000 (so they never practically expire)?

If you make your own certificates, you can. But you shouldn't. The cryptography behind certificates ages, attackers get more powerful, machines get broken into, keys get stolen. In theory, we have revocation for that, in practice it's... hairy. And that assumes you know there's an issue. Having certificates naturally expire after some time eases these problems a little. For that reason, having a 3000-year certificate is highly discouraged.

If you obtain certificates from a CA, you can't because they won't give you one, for the reasons above. Typical lifespan for certificates is one year. In fact, browsers are moving to block long-lived certificates.

I like https, but I despise paying money for official keys.

Then use a free certificate. They are offered by several parties. I like Let's Encrypt.

Here's why: With self generated keys, the encryption of the communication is just as secure as a purchased key.

No, it's not. At least, not if the browser complains.

The encryption of the channel is only secure if the certificate can be trusted. If you use a self-signed certificate, the browser has no way to trust the certificate (hence the warnings), which means a man-in-the-middle attack is possible just like it is for plain HTTP. The attacker can simply substitute their own certificate; your client has no way of knowing the certificate has been forged.

This is were CAs come in; they offer a way for browsers to have reasonable trust in a certificate.

You can avoid this problem by distributing your self-signed certificate yourself; if you do that properly, the connections will be perfectly secure. But this is more work, and scales poorly, which is why we use CAs for non-trivial situations.

Yet, the browser makes the user think he's going to get a virus if he accepts my generated certificate. The browser treats everything like online banking, when sometimes you have other reason for encryption. Ok, enough complaining.

Browsers are very right to be vocal about this; blindly accepting untrusted certificates gives a false sense of security; it's barely better than plain HTTP. It is rarely the right thing to do, and it almost always indicates a serious problem. Scaring users away is for the best.

So, ideally, I want one a key I can generate myself (to avoid fees), or maybe one key I purchase

You always generate the key yourself; I think you mean the certificate ;)

Anyway, use a CA. There are free ones available.

but I want that key to practically never expire

Ain't gonna happen.

and I want it to serve multiple installations (at different companies) for my app.

Bad idea; you want to isolate your customers from a compromise at another customer as much as possible, especially if you're going to distribute your own certificates.