The only difference between a trusted and untrusted CA cert is that... the former is trusted.
There are two ways this can happen: 1) The client software (e.g. browser) has certain lists of trusted certs built in. Others have already explained how to get on that list in far better detail than I. 2) For closed environments, it is likely possible (and certainly possible in the case of browser clients), to ADD your own cert to that list. 2b) For managed environments, where PCs are administered from a central location step (2) above can be automated. I'm thinking of Windows-boxes here more than others, as Microsoft is actually fairly good about such things. The idea is that desktop changes can be pushed from a single trusted IT location. For your test environment (2b) is likely overkill, and (2) will suffice. -----Original Message----- From: owner-openssl-us...@openssl.org on behalf of Dallas Clement Sent: Sat 5/29/2010 5:49 AM To: openssl-users@openssl.org Subject: Re: How to make a legit CA cert? Thanks all for the information. This is good stuff to know too. What I was really trying to understand is the nuts-n-bolts mechanics of how a legit CA certificate differs from a self-created one (I know, this is a dumb question...) For example, I can create my own for test purposes this way: openssl genrsa -des3 -out ca.key 4096 openssl req -new -x509 -days 365 -key ca.key -out ca.crt However, if I turn on cert verfication in my programs, this one gets rejects straight away (unknown CA). I presume the reason is because I have generated my own key to produce this cert. Is it possible to create a CA cert that looks and feels like a root cert issued from a legit company, like Verisign etc? I just want it to work in a test environment to ensure that cert verification works for both client and server certificates. Thanks again for your patience, Dallas On Sat, May 29, 2010 at 4:02 AM, Konrads Smelkovs <konr...@smelkovs.com> wrote: > As somebody who audits CAs for purpose of them getting into trusted root > list, this is what you have to do: > a) Obtain WebTrust for certification authorities or ETSI 101 456 standard (+ > EV guidelines from cabforum.org) > b) Implement systems in line with one of these standards. Not cheap. HSM > devices alone cost $10k & upwards. > c) Get somebody who is trustworthy (think accountants or one of Big 4 > auditor companies, i recommend KPMG as I work for them) and/or webtrust > accredited auditors (who can certify) to audit you. First time you will > almost fail, but if the auditor is an advisor, he'll help you through. Not a > cheap thing to do either. > d) Submit your application to microsoft trusted root list program, mozilla, > opera and everybody else. MS has deadlines on march and september for > submission > e) Every 12 months, repeat audit. > f) Ask yourself, do you really need it and get maybe some CA to cross sign > you. > > -- > Konrads Smelkovs > Applied IT sorcery. > > > On Sat, May 29, 2010 at 5:08 AM, Patrick Patterson <ppatter...@carillon.ca> > wrote: >> >> On 28-May-10, at 8:04 PM, Dallas Clement wrote: >> >>> This is probably a dumb question, but if I wanted to be come the next >>> Verisign of this world, how do I create a legitimate CA cert? I'd >>> like to be able to create my own that passes verification without >>> throwing errors, like "unknown CA". >>> >> Well, the first thing that you do, is do things that build "Trust", or the >> perception that you are trustworthy. Invest in hardware that will protect >> the CA's keys. Build processes that protect those keys. Use facilities that >> give the impression of trust (if you've ever been to Verisign HQ for a key >> ceremony, you'll appreciate the amount of "theater" that they do :). Then, >> document all of these in your "Certificate Policy" and Certification >> Practice Statement, along with all of the ways that you go about binding >> people or servers to their associated keys, and how you manage all of your >> personnel and facilities that are used in the operation of the CA, and >> issuance of certificates by that CA. When you cut your keys, do it in the >> presence of an auditor, and according to a proper key ceremony script. >> >> Once you have this, then get audited to prove that you are following your >> certificate policy. Most of the browser vendors, to be included in their >> "Trusted Roots" list, like to see a Webtrust audit. If you want to be >> included in the list that can validate EVSSL certs, then you have to also >> follow the guidelines of the CA/Browser forum. >> >> Most of the vendors, however, also have the caveat that in order to be >> included in their list, you have to be a commercial entity that are issuing >> certs to "John Q Public". If you only issue to people within a small, closed >> community, then you'll have to talk pretty fast to get them to accept your >> CA into their browser. >> >> That's it. If you need any help, give us a call :) >> >> --- >> Patrick Patterson >> President and Chief PKI Architect >> Carillon Information Security Inc. >> http://www.carillon.ca >> >> >> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-us...@openssl.org >> Automated List Manager majord...@openssl.org > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
<<winmail.dat>>
