[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-users] ipa-replica-prepare clarification

James Roman wrote:
Yes the valicert.com certificate did get installed in the DS cert database and then subsequently failed to install in the web server database. I can't find any output to indicate why it was missed. The answer to your next question is yes, I did specify the same PKCS12 certificate file and pin for the dirsrv and http options when I ran ipa-replica-prepare.

Now I am getting past the certificate trust failure, but have encountered a whole new set of problems. My Directory server is failing to start with the following error:

Starting dirsrv:
REALM-COM...[15/Sep/2009:09:39:18 -0400] dse - The entry cn=schema in file /etc/dirsrv/slapd-REALM-COM/schema/99user.ldif is invalid, error code 21 (Invalid syntax) - object class nsAIMpresence: Unknown allowed attribute type "nsaimid" [15/Sep/2009:09:39:18 -0400] dse - Please edit the file to correct the reported problems and then restart the server.

I am pretty sure I know why this is happening, I'm just not sure how I want to address it. My Master is a FC9 install, my replica is a FC10 install. My master was installed as FC9 due to issues loading FC10 into a Cent 5 Xen VM. Now that I've overcome those, I was hoping that I could go this route to provide a migration path. Perhaps not. This will be subject of a new thread.

I've seen this happen too, it is a bug in 389-DS I think. It doesn't happen all the time though, I've worked around it by trying the replica installation again.


Rob Crittenden wrote:
James Roman wrote:
I installed the 1.2.2-1 version from the test repo. I get really close to the end, but it is still bombing when trying to set the trust permissions on the web server cert. For some reason the final cert in the chain did not get installed into the /etc/httpd/alias directory. All worked fine for the directory server.

Strange, Does the valicert.com certificate exist in the DS database?

I guess I assumed that if the certificate was in the PKCS#12 file then it would be loaded by NSS. That doesn't seem to be the case.

This patch should help. It will log the failure of setting trust but will continue. If the certificate is indeed not needed then it shouldn't hurt anything.

diff --git a/ipa-server/ipaserver/certs.py b/ipa-server/ipaserver/certs.py
index 95e6ac7..3782acf 100644
--- a/ipa-server/ipaserver/certs.py
+++ b/ipa-server/ipaserver/certs.py
@@ -386,8 +386,11 @@ class CertDB(object):
          if root_nickname[:7] == "Builtin":
logging.debug("No need to add trust for built-in root CA's, skippi
-             self.run_certutil(["-M", "-n", root_nickname,
-                                "-t", "CT,CT,"])
+             try:
+                 self.run_certutil(["-M", "-n", root_nickname,
+                                    "-t", "CT,CT,"])
+             except ipautil.CalledProcessError, e:
+ logging.error("Setting trust on %s failed" % root_nickname)

     def find_server_certs(self):
         p = subprocess.Popen(["/usr/bin/certutil", "-d", self.secdir,

The file to modify on an installed system is /usr/lib[64]/python*/site-packages/ipaserver/certs.py

Let me know if this fixes it for you and I'll see about getting this committed.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]