Hi Oscar,
Consider this case, I created two Root CA's. 1. Test Root CA1 2. Test Root CA2 The Test Root CA2 has two Sub CA's 1. Test Level 1 CA2 2. Test Level 2 CA2 Is there a function, with which I can cross-certificate Test Root CA1 with Test Level1 CA2? The cross certificate functions with the Test Root CA1 and the Test Root CA2. openssl ca -config conf.cnf -preserveDN -ss_cert testrootca2.crt -out crossca.pem Thanks & Regards, Ravi Prakash "Ravi Prakash B.V." wrote: > > Hi Oscar, > > Thanks a lot. Most of the things are clear. > I will be very happy if you send the document ASAP.... > > Thanks in anticipation, > > Ravi > > Oscar Jacobsson wrote: > > > > Hi again! > > > > I'll attempt to answer the questions you have in-line below. I hope it's > > ok if I try to keep things as simple as possible right now, referring to > > the OpenSSL command-line tools as much as possible. > > > > PS. I hope to be able to start work on the tutorial during the day. > > > > //oscar > > > > "Ravi Prakash B.V." wrote: > > > Practically how it is possible...... > > > 1Q. Assume both parties have self signed certificates (root CA's), how > > > they will cross certify each other? > > > > The easiest way of doing this is to use the -ss_cert parameter to > > OpenSSL's ca command, which tags the input as a self-signed certificate > > to be "re-issued" by the specified issuer cert and key. > > > > I haven't peeked at the source yet, so I don't know how it will behave > > with regards to issuer key kdentifiers or path length constraints, which > > it might need to modify in order to keep the certification path valid. > > > > > 2Q. For cross certification, If each Root CA send their certificate > > > Requests to each other. How it is possible to cross certify without > > > having any existing CA certificate? > > > > Certificate requests are "lossy", and could conceivably leave out > > information that might be necessary to build valid chains, so it's > > probably easier to use option 1 above. Signing the certificate request > > would be done using the ca command as usual. > > > > > 3Q. will Cross certified root certificate contain two signatures (one is > > > self signed signature, other is signature of cross certified CA)? (but > > > as per x509 standards, there will be only one signature part) > > > > There will be only a single signature in a cross-certificate, as > > required by X.509. There is nothing special at all about a > > cross-certificate syntactically. A cross-certificate is simply a > > certificate issued to another certificate issuer. > > > > I hope to be able to make this much clearer in the promised document, > > even if UML is a bit of a mess to draw in ASCII. :-) > > > > > 4Q. Both root CA's have chain of sub-ca's and issue digital certificates > > > independently. After some time, both root CA's want to establish trust > > > with each other (if they get cross certified), > > > > As outlined above, "sub-ca's" are cross-certificates by definition. > > > > The more complex the two separate hierarchies are, the more work will > > have to go into "joining" them through cross-certification. I'm quite > > sure that two messy enough certificate hierarchies might well be > > impossible to merge. > > > > There are also issues where you have a large number of parties wishing > > to interoperate, as the number of cross-certificates required would grow > > exponentially (n^2 - n, where n is the number of involved parties.) This > > can be solved by using a bridge-CA model where the number of cross > > certificates would simply grow at a rate of 2n. > > > > > Is there any implication on the existing digital certificates issued by > > > root CA's or will they have to get new certificates? I have no idea at > > > all.... > > > > The existing certificates should remain the same. The result of the > > process should be two new cross-certificates: one using the information > > in root certificate a issued by root b, and one using root b issued by > > root a. A uses the latter in order to verify certificates issued by root > > b, and b uses the former to verify certs issued by a. > > > > Hope that made sense. I promise I'll make this clearer as soon as I get > > some time to organize the information. :-) > > > > //oscar > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > Development Mailing List [EMAIL PROTECTED] > > Automated List Manager [EMAIL PROTECTED] > > -- > I am NOMAD! > > ------------------------------------------------------------------------ > Name: ravi.vcf > ravi.vcf Type: VCard (text/x-vcard) > Encoding: 7bit > Description: Card for Ravi Prakash B.V. -- I am NOMAD!
begin:vcard n:Venkata Ravi Prakash;Burlagadda tel;cell:98490 30284 tel;home:08644 26681 tel;work:040 6328079(direct) 040 7814515/17/19 extn:387 x-mozilla-html:FALSE org:Tata Consultancy Services;Advanced Technology Centre version:2.1 email;internet:[EMAIL PROTECTED] title:ASE adr;quoted-printable:;;1-2-10, Coramandel House,=0D=0ASardar Patel Road;Secunderabad;AP;500003;India x-mozilla-cpt:;28992 fn:Burlagadda Venkata Ravi Prakash end:vcard
