Bug 573038

We are working on finding a solution and prioritizing the work. It might take us some time to figure out the best course of action.

Thank you for the update, Dmitri.


In the meantime, could you be so kind to clarify the next few points ?


1. For the moment being, further testing Dogtag on RHEL5 by me is rather useless, as you seem to confirm that Dogtag on RHEL is flawed ?


I am ware BZ is not for user support, but anyway :

2. I'd like to primarily setup an SSL certificate for our emerging 389 DS (to secure ldaps traffic).
Probably a stupid question, but here it goes :
Can I for now create a Dogtag PKI on a Fedora12 virtual machine, and later - once a solution for Dogtag on RHEL/CentOS has been found - transfer the created PKI (/etc/pki-ca/ etc.) entirely to a Dogtag RHEL installation (different MAC & IP address, etc.) without invalidating the certificates ?

3. Or should I alternatively create a self-signed certificate on the DS, and later import this into Dogtag ?

I would like to prevent a situation in which I have to revoke and reissue LDAP SSL certificates after the LDAP server has been deployed in production.

(In reply to comment #3)
> Thank you for the update, Dmitri.
> 
> 
> In the meantime, could you be so kind to clarify the next few points ?
> 
> 
> 1. For the moment being, further testing Dogtag on RHEL5 by me is rather
> useless, as you seem to confirm that Dogtag on RHEL is flawed ?
> 

I confirm that the EPEL version does not work. 
One of the reasons is that it requires a later version of one of the packages than the one that is currently available from the OS channel. We need to reconcile it. There are other EPEL issues too that we are looking at.
 

> 
> I am ware BZ is not for user support, but anyway :
> 
> 2. I'd like to primarily setup an SSL certificate for our emerging 389 DS (to
> secure ldaps traffic).
> Probably a stupid question, but here it goes :
> Can I for now create a Dogtag PKI on a Fedora12 virtual machine, and later -
> once a solution for Dogtag on RHEL/CentOS has been found - transfer the created
> PKI (/etc/pki-ca/ etc.) entirely to a Dogtag RHEL installation (different MAC &
> IP address, etc.) without invalidating the certificates ?
> 
> 3. Or should I alternatively create a self-signed certificate on the DS, and
> later import this into Dogtag ?
> 
> I would like to prevent a situation in which I have to revoke and reissue LDAP
> SSL certificates after the LDAP server has been deployed in production.    

I will pass this to our experts.

(In reply to comment #4)
> (In reply to comment #3)
> > Thank you for the update, Dmitri.
> > 
> > 
> > In the meantime, could you be so kind to clarify the next few points ?
> > 
> > 
> > 1. For the moment being, further testing Dogtag on RHEL5 by me is rather
> > useless, as you seem to confirm that Dogtag on RHEL is flawed ?
> > 
> 
> I confirm that the EPEL version does not work. 
> One of the reasons is that it requires a later version of one of the packages
> than the one that is currently available from the OS channel. We need to
> reconcile it. There are other EPEL issues too that we are looking at.
> 
> 
> > 
> > I am ware BZ is not for user support, but anyway :
> > 
> > 2. I'd like to primarily setup an SSL certificate for our emerging 389 DS (to
> > secure ldaps traffic).
> > Probably a stupid question, but here it goes :
> > Can I for now create a Dogtag PKI on a Fedora12 virtual machine, and later -
> > once a solution for Dogtag on RHEL/CentOS has been found - transfer the created
> > PKI (/etc/pki-ca/ etc.) entirely to a Dogtag RHEL installation (different MAC &
> > IP address, etc.) without invalidating the certificates ?
> > 
> > 3. Or should I alternatively create a self-signed certificate on the DS, and
> > later import this into Dogtag ?
> > 
> > I would like to prevent a situation in which I have to revoke and reissue LDAP
> > SSL certificates after the LDAP server has been deployed in production.    
> 
> I will pass this to our experts.    

Didier,

Starting off in a vm and then migrating will work, but there are a couple of things that you'll need to work through first.

I would start with the CS8 migration guide.  Its designed for CS7.x to 8, but it will provide you with a good overview of the steps and the things you will need to consider.  If can be found at http://www.redhat.com/docs/manuals/cert-system/8.0/migration/html/index.html

Now, as far as different names, ip addresses and such:  The docs do not currently state this, but they will be updated shortly.  A note for the security domain migration:
"Changing either the instance name or the fully-qualified domain name is not supported for migration. The fully-qualified domain name of the host machine for the new instance must be the same as the fully-qualified domain name of the original instance.  Similarly, the new instance  name must also be the same as the original instance name."

Another option that may work here is cloning.  Again, the CS8 docs can be a good guide here.  Check out http://www.redhat.com/docs/manuals/cert-system/8.0/deploy/html/sect-Deployment_Guide-Planning_Your_CRTS-Arranging_the_Certificate_Authority_Hierarchy.html#sect-Deployment_Guide-Certificate_Manager_Flexibility_and_Scalability-CA_Cloning

and 

http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/Cloning_a_Subsystem.html

and probably the one you will want to be sure and check out - converting cloned CAs:

http://www.redhat.com/docs/manuals/cert-system/8.0/install/html/converting-masters-and-clones.html#converting-ca-clones


HTH,

-kent

Thank you for your extensive answer, Kent ; this should get me on the road until the EPEL issues are solved.


One final question (and now we're really out of scope for this BZ, my apologies), concerning migration and/or transfer (from e.g. Fedora12 to RHEL5) and the FQDN issue :
would it be a valid option to use an ethernet alias (e.g. eth0:1) with its own IP address and FQDN, and use this to seamlessly transfer the PKI to it final destination ?

e.g. PKI on interim server (F12) :
- eth0:0 192.168.1.100 fedora12.domain.org
- eth0:1 192.168.1.123 cert.domain.org  <-- PKI
moves to final destination (RHEL5) :
- eth0:0 192.168.1.101 rhel5.domain.org
- eth0:1 192.168.1.123 cert.domain.org  <-- PKI

I guess the issue would be to assign the PKI to eth0:1, and not eth0:0 ?

(sincere apologies if this is handled in the docs you're referring to, I have not yet read them).

(In reply to comment #6)
> Thank you for your extensive answer, Kent ; this should get me on the road
> until the EPEL issues are solved.
> 
> 
> One final question (and now we're really out of scope for this BZ, my
> apologies), concerning migration and/or transfer (from e.g. Fedora12 to RHEL5)
> and the FQDN issue :
> would it be a valid option to use an ethernet alias (e.g. eth0:1) with its own
> IP address and FQDN, and use this to seamlessly transfer the PKI to it final
> destination ?
> 
> e.g. PKI on interim server (F12) :
> - eth0:0 192.168.1.100 fedora12.domain.org
> - eth0:1 192.168.1.123 cert.domain.org  <-- PKI
> moves to final destination (RHEL5) :
> - eth0:0 192.168.1.101 rhel5.domain.org
> - eth0:1 192.168.1.123 cert.domain.org  <-- PKI
> 
> I guess the issue would be to assign the PKI to eth0:1, and not eth0:0 ?
> 
> (sincere apologies if this is handled in the docs you're referring to, I have
> not yet read them).    

Using a vip should be fine, as long as dogtag is configured to use it (security domain, etc).  then migrating will be ok, as long the the fqdn stays the same.

I don't like giving "should" answers, but I have not done it on a vip.  I do not see any reason why it would not work, though.

-kent

Well, rest assured I'll file a BZ if it doesn't.   :)

Thank you for the advice.

Created attachment 405062 [details]
EPEL fix for "_sharedstatedir" macro on RHEL

References:

* http://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions
* http://fedoraproject.org/wiki/Packaging/DistTag

Created attachment 405063 [details]
EPEL fix for "_sharedstatedir" macro on RHEL

References:

* http://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions
* http://fedoraproject.org/wiki/Packaging/DistTag

Created attachment 405065 [details]
EPEL fix for "_sharedstatedir" macro on RHEL

References:

* http://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optflags_and_admonitions
* http://fedoraproject.org/wiki/Packaging/DistTag

attachment (id=405062)
attachment (id=405063)
attachment (id=405065)
+awnuk

See also 'Bugzilla Bug #568787 - pki-ca fails to create SSL connectors'



# cd tomcatjss

# svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^?
M       tomcatjss.spec
M       build_tomcatjss
M       build.xml

# svn commit
Sending        build.xml
Sending        build_tomcatjss
Sending        tomcatjss.spec
Transmitting file data ...
Committed revision 88.



# cd pki/base

# svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^?
M       config/release.xml

# svn commit
Sending        base/config/release.xml
Transmitting file data .
Committed revision 1029.



# cd pki/dogtag

# svn status | grep -v ^$ | grep -v ^P | grep -v ^X | grep -v ^?
M       common/pki-common.spec
M       config-ext/build_dogtag_pki
M       util/pki-util.spec

# svn commit
Sending        dogtag/common/pki-common.spec
Sending        dogtag/config-ext/build_dogtag_pki
Sending        dogtag/util/pki-util.spec
Transmitting file data ...
Committed revision 1030.

Confirmed fixed in current EPEL-testing rebuilds.