Thanks a lot <div><br></div><div>All this while I was using a Microsoft external CA. </div><div><br></div>Another doubt I had:<br><div>Do we have a way we're we can just provide a public private key pair in a particular location and dogtag will always use that as root cert? </div><div>Something like providing a static root certificate ?</div><div><br></div><div>Regards </div><div>Kritee<br><div><br>On Thursday, 16 October 2014, Ade Lee <<a href="mailto:alee@redhat.com">alee@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2014-10-16 at 07:21 +0530, Kritee Jhawar wrote:<br>
> Thanks for the response<br>
><br>
> I got the setup to work with external CA just yesterday. This time I used a dogtag as the external CA rather than OpenSSL and Microsoft.<br>
><br>
OK, I suspected that the cert being used as the external CA cert was the<br>
problem.  As I recall, there is a current bug being fixed to address<br>
issues with Microsoft issued CA certs.  If you can use a dogtag cert as<br>
your external CA, then you'll avoid any issues.<br>
<br>
> I'll have multiple instances of dogtag in my deployment. Ideally I want all of them to come up with these root certificate. Is there some location I can place a public private key pair wich dogtag uses to come up ?<br>
><br>
I don't understand what you are trying to do here.  You have created<br>
several dogtag CA's that are subordinate to the external CA.  They are<br>
CA's in their own right, with their own signing certificates.  Why do<br>
they need access to the root CA?<br>
<br>
If you want several CA's with exactly the same signing cert, then you<br>
want clones.<br>
<br>
> Also what I meant by services not coming up was not other components like KRA and DRM.<br>
> I just have the CA subsystem and even though it was getting spawned wo were unable to use it.<br>
><br>
> Thanks<br>
> Kritee<br>
><br>
> Sent from my iPhone<br>
><br>
> > On 16-Oct-2014, at 00:44, John Dennis <<a href="javascript:;" onclick="_e(event, 'cvml', 'jdennis@redhat.com')">jdennis@redhat.com</a>> wrote:<br>
> ><br>
> >> On 10/10/2014 07:14 AM, kritee jhawar wrote:<br>
> >> Dogtag is the private CA for multiple services in a cluster. Trust is<br>
> >> established by providing the root certificate of dogtag to all the<br>
> >> services. What happens if dogtag crashes? All the services will have to<br>
> >> be given the root certificate of the new dogatg.<br>
> >><br>
> >> How can we avoid this?<br>
> ><br>
> > Why do you need to re-provision the services with a new root certificate<br>
> > if Dogtag crashes? Why not just restart the Dogtag instance with the<br>
> > existing certs? It sounds like you're throwing away the old instance and<br>
> > creating a new Dogtag instance needlessly.<br>
> ><br>
> > Also, I don't understand why your services won't run if Dogtag isn't<br>
> > currently running (unless you're using OCSP). Dogtag provisions certs, a<br>
> > service using a cert issued by Dogtag doesn't need to communicate with<br>
> > Dogtag unless you're using OCSP). As long as your services have been<br>
> > provisioned with the certs issued by Dogtag they should run fine (or are<br>
> > you issuing very short duration certs that need constant refreshing?)<br>
> ><br>
> > FWIW, what you describe, re-provisioning of a new CA cert is exactly<br>
> > identical to handling an expired CA cert. There was documentation<br>
> > written up recently on how to handle expiring CA certs but I don't have<br>
> > a pointer to it, sorry. But as I mentioned above I don't you need to<br>
> > replace the certs, you just need to restart the service.<br>
> ><br>
> > If the instance is crashing then that's a bug that needs fixing. Please<br>
> > file a bug report so the problem can get fixed.<br>
> ><br>
> > Ade can comment on the specific errors you reported.<br>
> ><br>
> > --<br>
> > John<br>
<br>
<br>
</blockquote></div></div>