Ian Stokes-Rees wrote:

Just so I have the full context, where did the original self-signed
cert come from? The initial cert should have been good for 12 months
so I'm a little confused. Do you know where the initial certificate
came from?

I have to plead ignorance, since it was our regular sys admin (away on
vacation for 2 weeks) who installed this summer of 2010.  I'm a "user"
stuck with managing the system while he's away.  I assume this cert came
from the default installation process.  He chimed in with a quick
comment on our internal ticket, and said he doesn't know any details
about the cert infrastructure of FreeIPA.


Ouch, you have my sympathies.

You're running a pretty old build so maybe we didn't have this quite
working but we use a tool named certmonger to keep the SSL
certificates valid. It could be that we weren't using certmonger then,
or not enabling it correctly, I'm not sure.If you want to see then as
root run: ipa-getcert list. This will show you the certificates that
certmonger is monitoring (and I suppose it could be none or you could
get a DBus error.

Probably not running it:

# ipa-getcert list
Error org.freedesktop.DBus.Error.ServiceUnknown: The name
org.fedorahosted.certmonger was not provided by any .service files


Ok, that's fine. Maybe we can use it once you get up and running again, but first things first.


Since your infrastructure is probably down because of this here are
the instructions you need to get going again. I hesitate because I
don't want to make things worse for you by not understanding the history.

The Directory Manager is essentially the super-user of 389-ds. It gets
a separate password when IPA is installed. See these instructions for
resetting it:
http://directory.fedoraproject.org/wiki/Howto:ResetDirMgrPassword

Seemed straight forward, but it hasn't worked.  After changing the
password in the dse.ldif file I can't restart "dirsrv" successfully: our
instance won't restart, but the PKI-IPA one will restart just fine.  In
either case, I can't execute the ipa-server-certinstall, as I get an error:

# ipa-server-certinstall -d ldap-selfsigned-to20120120.pkcs12
--dirsrv_pin=ldap
Directory Manager password:
an unexpected error occurred: Can't contact LDAP server:
[stacktrace]
DatabaseError: Can't contact LDAP server:

/me smacks head

Ok, of course you can't contact the LDAP server because it isn't up because the cert is expired!

Also, I should reiterate that the PKCS#12 file is *self signed*, but I
notice in /etc/ipa/ca.crt there is a cert (just public) for the IPA CA
-- perhaps my cert needs to be signed by this CA?

Yes, that was going to be my next question. While throwing any old self-signed cert in there might get the server up other things won't work, notably replication.

Ok, here are some steps I worked out that I think will get you back in business. I'm going to try to renew your 389-ds certificate using IPA.

First we need to get 389-ds back up and running.

I'm going to use REALM in place of the instance name for your 399-ds install.

1. Make a backup of /etc/dirsrv.slapd-REALM/dse.ldif
2. Make a backup of your dirsrv NSS database (so /etc/dirsrv/slapd-REALM/*.db)
2. Edit dse.ldif and set nsslapd-security to off
3. Try starting dirsrv: service start dirsrv REALM
4. Get a kerberos ticket for admin: kinit admin
5. Generate a new CSR for your directory server:
certutil -R -k 'NSS Certificate DB:Server-Cert' -s 'cn=nebio-directory.in.hwlab,O=IPA' -d /etc/dirsrv/slapd-REALM/ -f /etc/dirsrv/slapd-REALM/pwdfile.txt -a > renew.csr
6. Get a new certificate:
ipa cert-request renew.csr --principal=ldap/nebio-directory.in.hwlab >
7. Paste the value in the output for Certificate into a file. This is a base64-encoded blob of text probably starting with MII and ending with ==.
8. Add this new cert to your 389-ds database
certutil -A -d /etc/dirsrv/slapd-REALM -n Server-Cert -t u,u,u -a < cert.txt
9. service dirsrv stop REALM
10. edit dse.ldif and set nsslapd-security to on
11. service dirsrv start REALM

I ran the majority of these steps against my own IPA installation and nothing caught on fire. I hope you have equal success.


I'm also curious why only the 389-ds cert has expired and not the
Apache cert (or maybe you haven't noticed it yet). 'certutil -L -d
/etc/httpd/alias -n Server-Cert' will show you.

Here you can see the expired cert and the 6 month lifespan:

# certutil -L -d /etc/httpd/alias -n Server-Cert
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number: 9 (0x9)
         Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
         Issuer: "CN=Certificate Authority,O=IPA"
         Validity:
             Not Before: Wed Jul 21 18:13:52 2010
             Not After : Mon Jan 17 18:13:52 2011
         Subject: "CN=nebio-directory.in.hwlab,O=IPA"


Wow, not sure why it would do a 6 month cert but seeing is believing.

regards

rob

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to