Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 9 down vote accepted

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.

share|improve this answer
    
That's a great suggestion - thanks (+1)! If I did that - if I set up my own private CA and asked my frontend servers to trust it, would my end users' browsers trust it? Or would they still get the nasty warning messages? –  zharvey Jul 2 '12 at 15:04
    
@AdamTannon Your end users would communicate with your frontend involving entirely different certificates from a trusted CA. That SSL connection does not go through the frontend, it ends there. –  Bart van Heukelom Jul 2 '12 at 15:06
    
Ahhh - so one more time (just so I completely understand): (1) my end users and my frontend servers communicate over a SSL cert generated from a known CA (like VeriSign); (2) as soon as the request is consumed from my frontend server, all subsequent communication uses SSL certs generated by either: (a) OpenSSL, or (b) my own CA that I set up. Am I on target? And thanks again! –  zharvey Jul 2 '12 at 15:16
2  
@AdamTannon Almost, OpenSSL is not a CA, but the tool that you use to create certificates, whether with a CA or not. When compared with passports, CA = Government, OpenSSL = Printer –  Bart van Heukelom Jul 2 '12 at 15:29

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.
share|improve this answer
    
Awesome answer (+1) - thank you Shivam; I wish I could split the "green check" between both you and @Bart but Bart was first ~ thanks again! –  zharvey Jul 3 '12 at 10:34
1  
If you configure the code to ignore any SSL warnings, you lose the authentication part of SSL. You don't if you manually install the trusted certificates. –  Bart van Heukelom Jul 3 '12 at 10:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.