Internal SSL Certificates?

Question

As a developer I really like the idea of using OpenSSL to get perfectly good, free, SSL certs. Unfortunately, from all the research/analysis I've done so far, it doesn't look like there is any way to use OpenSSL in such a way that my web users' browsers will trust the certs it generates for me.

It looks like, in order to avoid my users getting nasty warning messages from their browsers (complaining that my OpenSSL-generated certs aren't trusted/verified), I'm going to have to use a major vendor like Trustwave, VeriSign, etc.

I'm wondering if there is such a concept of "public" vs. "private" SSL certs? By that, I mean, I would buy a "public" SSL cert from one of these vendors, and would use that for all communication between my users' browsers and my public-facing HTTP servers. But once a server-side message is consumed, it would communicate with the rest of the back-end using different, "private" (OpenSSL-generated) certificates.

The idea behind this is to keep data moving through my backend using secure transports, but not have to pay for a bazillion different SSL certs.

Is this unheard of or completely unnecessary? Or is this standard practice?

Why would I need that data to be secure between 2 of my own backend servers? I don't know. Probably doesn't need to be, but probably couldn't hurt. Thoughts?

Answer 1

Yes, for your backend you can just generate self-signed certificates with OpenSSL as you have already done. The difference is that you then need to instruct your frontend servers to trust those certificates (how depends on the platform used).

Alternatively you can set up your own private CA (certificate authority, e.g. Verisign) and have your frontend servers trust its root certificate, then use it to generate certificates for your backend servers. This makes it easier if you need to use many certificates, other than that there's no difference.

That is exactly how "public" certificates work, except that the root certs of well known CA's are bundled with e.g. browsers. They are trusted because they perform checks of e.g. your identity, and that's what they charge for, not for the technical aspects of creating a certificate.

Of course, there is the question of whether the frontend-backend communication needs to be secured. Does anybody have the possibility to listen on the line? That depends on your hosting setup.

Answer 2

The idea behind this is to keep data moving through my backend using secure transports, but not have to pay for a bazillion different SSL certs.

You can use http://www.startssl.com to issue you free certificates. I've used them before and it works well (shows a green lock) on all browsers I've tested so far. The free certificate allows you for one free subdomain as well.

If you are willing to shell out some money, then the Class 2 certificates from them allow wildcards which means you can have a certificate for *.yourdomain.comand you can use it to validate all your subdomains eg. mail.yourdomain.com, ftp.yourdomain.com etc. with a single certificate.

Again you can use OpenSSL certificates for internal communication as Bart suggested. They way that will work is:

• Your external web-facing site uses a certificate (provided by startSSL or verisign).
  • Your visitors access it using https://www.yourdomain.com/whateverpage
  • Since it is from a valid CA (which is recognized and trusted by browsers), your users will never see a SSL warning. Period.
• Now suppose from your code, you need to call an internal (REST/SOAP) api hosted on an internal machine.
  • You call it from your code (using a rest/soap/whatever client) as https://10.23.42.23/getDetails?user=blah. Assuming this service is running on a different web-server instance, it can use a openSSL SSL certificate that you've created. When your code from yourdomain.com queries this API over https, it will be over SSL (hence encrypted) and since your API is not consumed by a browser, it will obviously not flag any SSL errors to the user.
  • You may however be required to configure your code (REST/SOAP client) to ignore any SSL warnings.

Owing to lack of the knowledge of your exact architecture, I've made generalizations in my example, however it conveys the basics.

Is this unheard of or completely unnecessary? Or is this standard practice?

Its not uncommon to see this kind of setup, so you are definitely thinking in the right direction.

Why would I need that data to be secure between 2 of my own backend servers? I don't know. Probably doesn't need to be, but probably couldn't hurt. Thoughts?

It won't hurt having data flowing between backend servers over SSL as well. There are a couple of benefits.

• You may not want an internal employee to hook up a tcpdump on a intermediary machine(through which data flows) and snoop the traffic. With SSL, she is out of luck.
• What if you want to move the functionality of one of your backend machine out of your network (embrace the cloud - amazon/rackspace). Guess what, you won't have to do anything extra to secure the communication. That's already covered. (New issues of MITM arise, but thats a different story)
• Defense in Depth preaches to have multiple layers of security. I'd definitely prefer internal communication over SSL if its feasible. A practical study establishes that SSL/TLS is not computationally expensive any more. So burdening the server is no longer a concern.

Answer 3

I've been using xca to maintain an internal Certificate Authority & generate server & client TLS certificates.

• This guide for xca was helpful

With xca it is simple to set additional x509 Subject Alternative Namefor certificates that may apply to multiple hosts / domains. The database is password protected & you can also set individual passwords on each private key (or by default private keys are aes encrypted with the database password). 100 character long passwords work (approx 512bits of entropy)

It is probably worthwhile to use TLS certs with 1 year validity even for internal purposes.

For user browsers to trust certificates the CA file will need to be installed in their browser (under Privacy & Security on any chrome based browser) or in their system certificate store.

Nowadays it is relatively simple to secure communications between remote systems with Wireguard. However I still use TLS even over a vpn connection as you never know where the next vulnerability will be.