6

I'm sorry if this is a dumb question. I'm new to all this.

I have a large number of users. I need to be able to generate SSL certs for various internal domain names. All of these certs need to be accepted by the browsers. It is my understanding that I need to generate a Certificate Authority like this article shows: https://web.archive.org/web/20121016162010/http://www.tc.umn.edu/~brams006/selfsign.html

Then with that certificate authority I can sign a signing request for each domain we need to support. That will give me a X509 cert that I can use with our web servers.

So, my questions are:

  1. WHAT generated files do I need to put(install, import, accept, etc) WHERE in order to get my browsers to trust all the certs generated by my CA? I'm sure the WHERE depends on the Browser and OS, right?
  2. I need to make it as easy as possible for my users to accept my CA. Unfortunately I don't have the ability to automatically push anything. The best thing I can do is provide a link. So, I was wondering if it would be possible to create an html page that is loaded over http (not secure) that has an iframe that is loaded from one of the secure servers. In theory, the iframe page will give some kind of message and allow installation. My outer page could give instructions on what the user needs to do. Would that work or am I missing something? If they do accept the cert will it work for all certs generated by my CA or just this one?
pacoverflow
  • 262
  • 1
  • 10
user548971
  • 193
  • 1
  • 4
  • 1
    Are you users internal to your company? Do you a Windows Active Directory domain? – Bernie White Jun 10 '12 at 00:52
  • No, the users aren't within our network. :-( No Active Directory. We do have control of the router but we are somewhat limited in what we can do from the router. – user548971 Jun 10 '12 at 06:29
  • How many users? All you can do is provide your root CA cert (wrapping this in an installer program doesn't help) - Are they likely to be able to install certificates themselves? – symcbean Jan 05 '13 at 00:00
  • In light of comments and answers below, I should add an interesting suggestion. Antivirus software (e.g. Eset Nod32) adds to your system a root cert in order to scan SSL sites or e-mail (if you allow it). Maybe instead of teaching users to import certs, OP could write or hire programmer to write some app that would be distributed and it will install said cert to all major browsers. – Kitet Feb 17 '14 at 18:03

6 Answers6

3

Personally, I would start with a low-cost or free SSL certificate signed by a known and trusted CA for one domain.

Then at that https site that their browsers trust (and that they can recognize as one particular subdomain of your organization), give them an https link to download your CAs certificate with instructions on how to load your CA's certificates in all of the various browsers/OSes that they likely will use.

E.g., firefox: http://www.cyberciti.biz/faq/firefox-adding-trusted-ca/ or in google-chrome: navigate to chrome://chrome/settings/certificates

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
3

Internet Explorer uses the facilities provided by the OS; namely, the "root CA" that IE will trust are the root CA that Windows will trust, and these are located in the "Root" certificate store. See this page for some details.

Firefox has its own storage mechanism, regardless of what the host OS can do. See for instance this page for details.

Safari on MacOS X relies on what the OS provides, and it is called "KeyChain". See e.g. this page.

Chrome tends to use whatever mechanism is provided by the local OS (the Root store on Windows, KeyChain on MacOS X...). This has been known to change depending on the version, so it is hard to keep things up-to-date.

This Web page tries to keep track on how to install root certificates in various applications and OS, but it seems a bit old and does not look actively maintained.

Caution: Root CA are the trust anchors: everything the machine trusts comes from these root CA. Therefore, they are a very valuable target; attackers would just love to be able to insert their own root CA in the trust store of many user systems. Correspondingly, it is not a very good idea to train your users to add root CA to their store. The ones who succeed will just have demonstrated that they are vulnerable to suggestions of root CA installation...

Since you state that your users are not on your internal network, then I must infer that they are on "the Internet" at large, and your SSL servers are accessible under "public" names (i.e. with domains which exist in the worldwide domain name system). Therefore, you could use certificates from regular CA. Some are free. This will save you a lot of efforts, since such CA already have their root CA in the trust stores of everybody. As usual, the system which is easiest to install is the system which is already installed.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Your first link is not for Windows, but instead a copy of the link for Firefox -- and the Firefox link is now out of date; menu Edit / Preferences is gone and it's now hamburger / Options or about:preferences in the bar. Also, StartCom sold to WoSign who got caught misissuing and backdating and [have now been distrusted](https://security.stackexchange.com/questions/18919/are-there-technical-disadvantages-in-using-free-ssl-certificates) but LetsEncrypt is now a good free alternative. – dave_thompson_085 Jun 28 '18 at 06:02
2

If you're looking for a low cost and low complexity solution, how about getting a wildcard certificate from a real cert issuer such as godaddy that would already be trusted by all of your client browsers. As long as all your hostnames are on the same domain this should work for you. You can use it as the cert for as many host as you need as long as they're in the same domain (e.g. host1.myorg.com, host2.myorg.com, host3.myorg.com etc.)

Like @Thomas Pomin I would caution you to be very careful if you are asking browsers to trust certificates signed by your own CA - epsecially if they are not part of your internal network. If you're not very careful about the scope of who can access the CA and create certificates this could go south very quickly. (Google turktrust if you want an idea of a recent example of what could go wrong with issuing trusted certificates.)

monkeymagic
  • 101
  • 4
1

Okay, as you said it is browser or OS dependent, some ask if the user wants to install a certificate if one tries to load it in the browser, others it must be done entirely manually. One only needs the root certificate.

Another option you could consider is getting a CA certificate signed by another already trusted CA, but this could be out of your price range.

ewanm89
  • 2,043
  • 12
  • 15
  • So, assuming my CA was generated with these commands: openssl genrsa -des3 -out ca.key 4096 openssl req -new -x509 -days 365 -key ca.key -out ca.crt It would be the ca.crt that needs to be installed for the browsers to trust my generated certificates, correct? – user548971 Jun 09 '12 at 17:02
  • Yes, though personally I wouldn't use -des3 myself. – ewanm89 Jun 09 '12 at 20:28
  • Why wouldn't you use -des3? What would you use? I just copied that from the article I mentioned in my question. – user548971 Jun 10 '12 at 06:30
  • @user548971 It's fine, it's just encrypting the private key with Triple-DES, personally I think Triple-DES a kludge, but well, it's better than DES so the only other choice you have is IDEA or a non encrypted private key. – ewanm89 Jun 10 '12 at 11:38
  • ewanm89: huh? OpenSSL privatekey encryption (the legacy form, used by `genrsa`) also supports Blowfish, CAST, Camellia, and SEED, since at least 2010. In fact, although upstream has long supported IDEA, quite a few builds/packages omitted it because of the patent (now expired). – dave_thompson_085 Jun 28 '18 at 06:06
  • Oh, I'm an idiot, I think I got it swapped with openssh.... didn't read which I was commenting on... IIRC openssh private authorisations keys are 3-DES, it is a major contention with putty maintainer Simon Tatham. – ewanm89 Jun 30 '18 at 17:18
1

What we have here is a question and a pair of answers that are way out of date.

At the time I would have considered the private root certificate still considerable*; but today that is no longer good advice by any means at all. Let's Encrypt TLS certificates do the job better. If it's supposed to be reached by browsers across the internet, it can use Let's Encrypt, and you don't have to bug your users to install certificates anymore.

*I'm assuming there's a perfectly good reason a wildcard doesn't work

Joshua
  • 1,090
  • 7
  • 11
  • 1
    It's also worth mentioning that using DNS based domain validation with Letsencrypt also allows you to quite happily generate certificates for internal systems that you access only through your internal network. – Anthony the Engineer Nov 08 '21 at 21:45
0

Building a CA is not a very complex operation, yet it requires quite an amount of work. There are tools around that are intended to save from from a part ot that complexity, like the excellent xca. It comes with a nice documentation, even if you have to know how x509 certificates work, but everything is nicely kept in a database. You have to design your system (single CA or multi-level CA - the latter in a must in corporate environment where there are different teams for server and client certificates). The you prepare templates for the certificates and everything intergrates smoothly.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84