Edward Fochler wrote: > I've been using XCA as my program of choice for handling CA stuff. > It's nice, powerful, relatively friendly, etc. I create the root CA, > get all of my servers to trust that, and issue individual certs based > off of that CA for each of my servers. That much has worked very well. What is XCA? > > I didn't use any scripts for this. And I absolutely hate the openssl > command line options. Your mileage may vary. > > ED. > > On Jul 11, 2006, at 8:52 am, Rob Crittenden wrote: > >> Philip Kime wrote: >> >>> What a nightmare. >>> I tried to use the script on the Wiki but this isn't really set up >>> to do >>> this. I would like one CA and then to generate all of the DS and AS >>> certificates from this. I can't work out if I need to copy the CA >>> db or >>> just the .asc file to the other servers to generate the certs - it >>> seems >>> to need the key for the CA cert and also the noise and pwd files? I >>> finally got two servers on SSL but they won't replicate as they don't >>> like each other's certificates even though I had the CA certs on both >>> servers. >>> I have spent eight hours getting nowhere and will have to start again >>> from scratch. If there are any clues on how to: >>> Have one CA for all server certs >>> How to install this CA cert on all servers >>> What is needed for replication over SSL to work >>> >> >> It sounds like you're trying to use the setupssl.sh script from the >> How to at http://directory.fedora.redhat.com/wiki/Howto:SSL. It >> isn't really designed to be a poor-man's CA, as you're seeing. >> >> I can't help with the replication but I can help getting SSL set up. >> >> It should be possible to use this setupssl.sh script, here is one >> way. Just know that setting up a PKI infrastructure is hard (and >> harder to do properly). If this CA is going to be only used for the >> replication agreements it's probably fine. If you want to use it for >> web servers, client certificates, LDAP-based login, you may want to >> spend some time planning. >> >> In any case, let's jump right in. >> >> Normally when one has a CA you keep the key material locked away and >> just pulled it out when you want to issue a new certificate. If you >> really are going to use this just for replication agreements this is >> less a problem. >> >> I'm assuming you have 4 servers, A-D, and each server only 1 >> instance installed. >> >> So, start with server A, and blow away /opt/fedora-ds/alias/slapd- >> <instance>-*.db (or better, make a copy somewhere in case you ever >> want it). >> >> This is going to be our "master" server. Run setupssl.sh. >> >> You now have a self-signed CA that has issued a server certificate >> for server A. The nickname is Server-Cert. >> >> Now you could just copy this whole certificate database to the other >> machines, tweak setupssl.sh a bit, and re-run it and get your >> certificates that way, but you'd really be spreading your CA keys >> all over the place, so I'm not going to do that. >> >> Instead we're going to use the server A certificate database to >> generate the 3 remaining certificates we need. >> >> You'll do this 3 times: >> >> 1. edit setupssl.sh and find step 7 >> 2. replace myhost=`hostname --fqdn` with myhost="foo.domain.com" >> where foo.domain.com is the output of hostname -fqdn on the target >> server (B, C or D). >> 3. Find the certutil line 2 lines below this myhost statement you'll >> see something like "-m 1001". Increment this starting from 1003. >> This is the certificate serial number and it needs to be unique. >> 1002 is the server A admin server certificate. >> 4. in the same line you'll see -n "Server-Cert". This nickname needs >> to be unique, pick another one. It could be Server-CertB, a name, it >> isn't important as long as it is unique. >> 5. run setupssl.sh >> >> Now that you've done this 3 times, you now have in server A a >> certificate database with a CA certificate and 4 server certificates >> (5 if you count the admin one) >> >> IMPORTANT: there is a trailing dash (-) at the end of each -P >> argument. If you do not have this dash things will not work. >> >> Now we need to export the 3 other server certificates, we do this with: >> >> # cd /opt/fedora-ds/alias >> # ../shared/bin/pk12util -o serverb.p12 -P slapd-<instance>- -d . - n >> "Server-CertB" >> >> Do this for each of the 3 nicknames you created. >> >> Do the following on servers B - D. Note that the prefix for slapd- >> <instance> will likely be different for each server. >> >> 1. Copy the appropriate server?.p12 and the file cacert.asc to /opt/ >> fedora-ds/alias on the target server (B,C,D) >> 2. Remove/archive *.db >> 3. Generate a new database with: >> # ../shared/bin/certutil -N -P slapd-<instance>- -d . >> 4. Import the CA certificate with: >> # ../shared/bin/certutil -A -d . -P slapd-<instance>- -n "CA >> certificate" -t "CT,," -a -i cacert.asc >> 5. Import your server certificate with: >> # ../shared/bin/pk12util -i serverb.p12 -P slapd-<instance>- -d . >> -n "Server-CertB" >> 6. Check ownership/permissions of the database(s). They should be >> owned by nobody by default. >> >> I think it would probably best to do this just on Server A and B and >> give it a quick test. You can always go back and add in C and D later. >> >> This would be infinitely easier if you had a real CA. >> >> There are also easier ways to do this using a combination of the >> java console and the command-line, but I've stuck with the command- >> line here. >> >> rob >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20060712/09c077ae/attachment.bin
