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?

3 Answers 3


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.

  • 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
    Commented Jul 2, 2012 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. Commented Jul 2, 2012 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
    Commented Jul 2, 2012 at 15:16
  • 4
    @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 Commented Jul 2, 2012 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 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.
  • 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
    Commented Jul 3, 2012 at 10:34
  • 2
    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. Commented Jul 3, 2012 at 10:48
  • "SSL/TLS is not computationally expensive any more" is not well supported by the article you linked, even though it says that is the tldr. In the specific case of gmail, it is not. Further in the article it says "it's vitally important not to send lots of small packets with small records in them"... so it depends. Commented May 21, 2015 at 0:58

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

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .