[Fedora-directory-users] Converting a 4-way replication setup to SSL

Wed Jul 12 17:31:20 UTC 2006

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://listman.redhat.com/archives/fedora-directory-users/attachments/20060712/09c077ae/attachment.bin>