Timothy Murphy a écrit :

On Sat 17 Nov 2007, Quanah Gibson-Mount wrote:

...

You failed to set the CA Cert directive in slapd.conf, so it has no way of presenting its CA cert.

How do you do this, exactly?

TLSCACertificateFile path_to_your_CA_file

Wadi

Be default, the SLES 9.3 slapd.conf defines the CA Cert like this:

TLSCACertificatePath /etc/ssl/certs

That directory has lots of pem files in it with x509 symbolic links:

ls -C /etc/ssl/certs Password: 052eae11.0 6f5d9899.0 d4e39186.0 ICE-root.pem timCA.pem 18d46017.0 73912336.0 ddc328ff.0 ICE-user.pem tjhCA.pem 1e49180d.0 7651b327.0 dsa-ca.pem ICP-Brasil.pem vsign1.pem 1ef89214.0 8c401b31.0 dsa-pca.pem nortelCA.pem vsign2.pem 1f6c59cd.0 8caad35e.0 Equifax-root1.pem pca-cert.pem vsign3.pem 24867d38.0 91b8190d.0 expired RegTP-4R.pem vsignss.pem 2edf7016.0 a99c5886.0 f3e90025.0 RegTP-5R.pem vsigntca.pem 3ecf89a3.0 adbec561.0 f73e89fd.0 RegTP-6R.pem YaST-CA.pem 594f1775.0 b5f329fa.0 factory.pem rsa-cca.pem 69ea794f.0 c33a80d4.0 ICE-CA.pem thawteCb.pem 6bee6be3.0 ca-cert.pem ICE.crl thawteCp.pem

I think CA certs is set up correctly. Am I wrong about that?

Do I have to move /etc/openldap/server.{crt,key} to /etc/ssl/certs?

Do I have to create turn /etc/openldap/server.{crt,key} into a .pem file?

Do I have to create x509 symbolic links from /etc/openldap/server.{crt,key} to /etc/ssl/certs?

Thanks for your help.

---- Not all who wander are lost.

| ---- ___o | chuck.keagle@boeing.com Chuck Keagle | ------- \ <, | Work: (425) 865-1488 Enterprise Servers: HPC | ----- ( )/ ( ) | Cell: (425) 417-3434

-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Friday, November 16, 2007 6:28 PM To: Keagle, Chuck; openldap-software@openldap.org Subject: Re: Enabling TLS problem on openldap2-2.3.39

--On Friday, November 16, 2007 5:01 PM -0800 "Keagle, Chuck" chuck.keagle@boeing.com wrote:

...

I'm configuring slapd to use TLS. First I just want to

make it work,

...

then I'll go into requiring encryption.

The system is SLES 9.3 The openldap2 is 2.3.39 Other certifictes are in /etc/ssl/certs as specified by default in slapd.conf for openldap2 2.3.39.

The database is currently empty, just getting started.

Generated a self-signed x509 certificate cd /etc/openldap openssl genrsa 1024 >server.key chmod 0440 server.key chown root:ldap server.key openssl req -new -key server.key -x509 -days 100 -out server.crt Entered all the important stuff chmod 0444 server.crt

Checked certificate and it looked acceptable openssl x509 -text -in server.crt

Changed following lines in slapd.conf: TLSCertificateFile /etc/openldap/server.crt TLSCertificateKeyFile /etc/openldap/server.key

You failed to set the CA Cert directive in slapd.conf, so it has no way of presenting its CA cert.

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc

---

Zimbra :: the leader in open source messaging and collaboration

The 2.3 Admin Guide indicates in Section 12.2.1.2 that the TLSCACertificateFile directive can be used instead of the hash links.

If I switch to using hash links, is it OK to just cat the crt and key file together to create a pem file?

---- Not all who wander are lost.

| ---- ___o | chuck.keagle@boeing.com Chuck Keagle | ------- \ <, | Work: (425) 865-1488 Enterprise Servers: HPC | ----- ( )/ ( ) | Cell: (425) 417-3434

-----Original Message----- From: Keagle, Chuck Sent: Monday, November 19, 2007 10:37 AM To: Quanah Gibson-Mount; openldap-software@openldap.org Subject: RE: Enabling TLS problem on openldap2-2.3.39

Be default, the SLES 9.3 slapd.conf defines the CA Cert like this:

TLSCACertificatePath /etc/ssl/certs

That directory has lots of pem files in it with x509 symbolic links:

ls -C /etc/ssl/certs Password: 052eae11.0 6f5d9899.0 d4e39186.0 ICE-root.pem timCA.pem 18d46017.0 73912336.0 ddc328ff.0 ICE-user.pem tjhCA.pem 1e49180d.0 7651b327.0 dsa-ca.pem ICP-Brasil.pem vsign1.pem 1ef89214.0 8c401b31.0 dsa-pca.pem nortelCA.pem vsign2.pem 1f6c59cd.0 8caad35e.0 Equifax-root1.pem pca-cert.pem vsign3.pem 24867d38.0 91b8190d.0 expired RegTP-4R.pem vsignss.pem 2edf7016.0 a99c5886.0 f3e90025.0 RegTP-5R.pem vsigntca.pem 3ecf89a3.0 adbec561.0 f73e89fd.0 RegTP-6R.pem YaST-CA.pem 594f1775.0 b5f329fa.0 factory.pem rsa-cca.pem 69ea794f.0 c33a80d4.0 ICE-CA.pem thawteCb.pem 6bee6be3.0 ca-cert.pem ICE.crl thawteCp.pem

I think CA certs is set up correctly. Am I wrong about that?

Do I have to move /etc/openldap/server.{crt,key} to 

/etc/ssl/certs?

Do I have to create turn /etc/openldap/server.{crt,key} 

into a .pem file?

Do I have to create x509 symbolic links from 

/etc/openldap/server.{crt,key} to /etc/ssl/certs?

Thanks for your help.

---

Not all who wander are lost.

                      |     ----  ___o  |  chuck.keagle@boeing.com

Chuck Keagle | ------- \ <, | Work: (425) 865-1488 Enterprise Servers: HPC | ----- ( )/ ( ) | Cell: (425) 417-3434

...

-----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Friday, November 16, 2007 6:28 PM To: Keagle, Chuck; openldap-software@openldap.org Subject: Re: Enabling TLS problem on openldap2-2.3.39

--On Friday, November 16, 2007 5:01 PM -0800 "Keagle, Chuck" chuck.keagle@boeing.com wrote:

...

I'm configuring slapd to use TLS. First I just want to

make it work,

...

then I'll go into requiring encryption.

The system is SLES 9.3 The openldap2 is 2.3.39 Other certifictes are in /etc/ssl/certs as specified by

default in

...

...

slapd.conf for openldap2 2.3.39.

The database is currently empty, just getting started.

Generated a self-signed x509 certificate cd /etc/openldap openssl genrsa 1024 >server.key chmod 0440 server.key chown root:ldap server.key openssl req -new -key server.key -x509 -days 100 -out server.crt Entered all the important stuff chmod 0444 server.crt

Checked certificate and it looked acceptable openssl x509 -text -in server.crt

Changed following lines in slapd.conf: TLSCertificateFile /etc/openldap/server.crt TLSCertificateKeyFile /etc/openldap/server.key

You failed to set the CA Cert directive in slapd.conf, so it has no way of presenting its CA cert.

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc

---

Zimbra :: the leader in open source messaging and collaboration

--On November 19, 2007 5:34:14 PM -0800 "Keagle, Chuck" chuck.keagle@boeing.com wrote:

System in SLES 9.3 running openldap 2.3.39

I tried to create the x509 hash and it still failed the same way.

Here are the entries in slapd.conf (all in global section):

TLSCertificateFile /etc/ssl/servercerts/servercert.pem
TLSCertificateKeyFile /etc/ssl/servercerts/serverkey.pem
TLSCACertificatePath /etc/ssl/certs/
TLSCACertificateFile /etc/openldap/ldapServer.crt
TLSCACertificateKeyFile /etc/openldap/ldapServer.key

Pick one, or the other, format. Do not use both. I suggest the TLSCACertificatePath method with a hash. It is the only thing that has worked consistently for me (appears to be an openssl issue).

It fails exactly the same way:

# ldapsearch -x -Z -H ldap://testsvr.blv.boeing.com -b "" -s base

'objectclass=*' '+' '*' ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed ldap_result: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Did you ever set up ldap.conf/.ldaprc as I noted, with the pointers to the CA cert and hash, as I noted was required? Also, the pem file for the CA cert does not need to contain the key. Probably better for it not to, really.

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

I have yet to even change the error messages when trying:

# ldapsearch -x -Z -H ldap://testsvr.blv.boeing.com -b "" -s base 'objectclass=*' '+' '*' ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed ldap_result: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Can anyone point out what I have missed here?

*********************************** Here is /etc/openldap/slapd.conf

$ cat slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. #

##### # Global Confituation Parameters #####

include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/yast.schema #CBK modified logging to lots for debug purposes #CBK Log levels are additive, and available levels are: #CBK 1 (0x1 trace) trace function calls #CBK 2 (0x2 packets) debug packet handling #CBK 4 (0x4 args) heavy trace debugging (function args) #CBK 8 (0x8 conns) connection management #CBK 16 (0x10 BER) print out packets sent and received #CBK 32 (0x20 filter) search filter processing #CBK 64 (0x40 config) configuration file processing #CBK 128 (0x80 ACL) access control list processing #CBK 256 (0x100 stats) stats log connections/operations/results #CBK 512 (0x200 stats2) stats log entries sent #CBK 1024 (0x400 shell) print communication with shell backends #CBK 2048 (0x800 parse) entry parsing #CBK 4096 (0x1000 cache) caching (unused) #CBK 8192 (0x2000 index) data indexing (unused) #CBK 16384 (0x4000 sync) LDAPSync replication #CBK 32768 (0x8000 none) 32767 means all #CBK 0x141 = 321 loglevel -1 # Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org

pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args

##### # Backend Configuration Parameters #####

# Load dynamic backend modules: modulepath /usr/lib/openldap/modules # moduleload back_ldap.la # moduleload back_meta.la # moduleload back_monitor.la # moduleload back_perl.la

#CBK Comment out TLSCertificateFile and TLSCertificatekeyFile here. # Also, force encryption #CBK end #TLSCertificateFile /etc/ssl/servercerts/servercert.pem TLSCACertificatePath /etc/ssl/certs/ TLSCACertificateFile /etc/ssl/certs/ldapServer.pem #TLSCertificateKeyFile /etc/ssl/servercerts/serverkey.pem TLSCiphersuite HIGH security ssf=128

#CBK added for local use on SuSE 9.3 #TLSCACertificateFile /etc/openldap/cacert.pem #TLSCACertificateKeyFile /etc/openldap/ldapServer.key

# Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access to user password # Allow anonymous users to authenticate # Allow read access to everything else # Directives needed to implement policy: access to dn.base="" by * read

access to dn.base="cn=Subschema" by * read

access to attrs=userPassword,userPKCS12 by self write by * auth

access to attrs=shadowLastChange by self write by * read

access to * by * read

# if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! #CBK Added passwords stored here only for authentication #CBK Made them editable only by respective users #access to attrs=userPassword # by self write # by anonymous auth #CBK end

#CBK allow certain attributes to be edited by user #CBK allow same attributes to be only view by others #access to dn.regex="uid=(.*),ou=.*,dc=com" attrs=sn,givenName,homePhone,homePostalAddress,mobile # by self write # by users read #CBK end

#CBK Do not allow unauthenticated users to harvest email addresses. #access to dn.regex="uid=.*,dc=com" attrs=mail # by users read # by * none #CBK end

#CBK Allow read access to objects outside normal directory tree. #CBK root DSE is an important one here. #access to dn.regex=() # by * read #CBK end

#CBK allow authenticated users to read other attributes #CBK prohibit anonymous users from reading other attributes #access to * # by users read # by anonymous none

####################################################################### # bdb database definitions #######################################################################

##### # Database Configuration Parameters #####

#TLSCertificateFile /etc/openldap/servercert.pem #TLSCertificateKeyFile /etc/openldap/serverkey.pem database bdb # # CBK Modified suffix, rootdn, and rootpw for local environment # CBK Added Mode for local environment # suffix "dc=testsvr,dc=blv,dc=boeing,dc=com" rootdn "cn=Manager,dc=testsvr,dc=blv,dc=boeing,dc=com" rootpw "{SSHA}Wq/1kuD3yROp6CU9CCkSOBiJm2GWhnpW" Mode 0600 directory /var/lib/ldap checkpoint 1024 5 cachesize 10000 index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres

*********************************** Here is /etc/openldap/ldap.conf

$ cat ldap.conf # # LDAP Defaults #

# See ldap.conf(5) for details # This file should be world readable but not world writable.

#CBK Uncommented and set BASE and URI for local environment BASE dc=blv,dc=boeing, dc=com URI ldaps://testsvr.blv.boeing.com

#SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_REQCERT allow #CBK Added for self-signed certificate HOST testsvr.blv.boeing.com

TLS_CACERT /etc/ssl/certs/ldapServer.pem

Here are the ldap log entries when loglevel = -1

Nov 21 23:08:54 testsvr slapd[12709]: daemon: activity on 1 descriptor Nov 21 23:08:54 testsvr slapd[12709]: daemon: activity on: Nov 21 23:08:54 testsvr slapd[12709]: Nov 21 23:08:54 testsvr slapd[12709]: >>> slap_listener(ldap:///) Nov 21 23:08:54 testsvr slapd[12709]: daemon: listen=8, new connection on 14 Nov 21 23:08:54 testsvr slapd[12709]: daemon: added 14r (active) listener=(nil) Nov 21 23:08:54 testsvr slapd[12709]: conn=11 fd=14 ACCEPT from IP=130.42.48.144:1180 (IP=0.0.0.0:389) Nov 21 23:08:54 testsvr slapd[12709]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 21 23:08:54 testsvr slapd[12709]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 21 23:08:54 testsvr slapd[12709]: daemon: activity on 1 descriptor Nov 21 23:08:54 testsvr slapd[12709]: daemon: activity on: Nov 21 23:08:54 testsvr slapd[12709]: 14r Nov 21 23:08:54 testsvr slapd[12709]: Nov 21 23:08:54 testsvr slapd[12709]: daemon: read active on 14 Nov 21 23:08:54 testsvr slapd[12709]: connection_get(14) Nov 21 23:08:54 testsvr slapd[12709]: connection_get(14): got connid=11 Nov 21 23:08:54 testsvr slapd[12709]: connection_read(14): checking for input on id=11 Nov 21 23:08:54 testsvr slapd[12709]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 21 23:08:54 testsvr slapd[12709]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 21 23:08:54 testsvr slapd[12709]: do_extended Nov 21 23:08:54 testsvr slapd[12709]: do_extended: oid=1.3.6.1.4.1.1466.20037 Nov 21 23:08:54 testsvr slapd[12709]: conn=11 op=0 STARTTLS Nov 21 23:08:54 testsvr slapd[12709]: send_ldap_extended: err=0 oid= len=0 Nov 21 23:08:54 testsvr slapd[12709]: send_ldap_response: msgid=1 tag=120 err=0 Nov 21 23:08:54 testsvr slapd[12709]: conn=11 op=0 RESULT oid= err=0 text= Nov 21 23:08:54 testsvr slapd[12709]: daemon: activity on 1 descriptor Nov 21 23:08:54 testsvr slapd[12709]: daemon: activity on: Nov 21 23:08:54 testsvr slapd[12709]: 14r Nov 21 23:08:54 testsvr slapd[12709]: Nov 21 23:08:54 testsvr slapd[12709]: daemon: read active on 14 Nov 21 23:08:54 testsvr slapd[12709]: connection_get(14) Nov 21 23:08:54 testsvr slapd[12709]: connection_get(14): got connid=11 Nov 21 23:08:54 testsvr slapd[12709]: connection_read(14): checking for input on id=11 Nov 21 23:08:54 testsvr slapd[12709]: connection_read(14): TLS accept failure error=-1 id=11, closing Nov 21 23:08:54 testsvr slapd[12709]: connection_closing: readying conn=11 sd=14 for close Nov 21 23:08:54 testsvr slapd[12709]: connection_close: conn=11 sd=-1 Nov 21 23:08:54 testsvr slapd[12709]: daemon: removing 14 Nov 21 23:08:54 testsvr slapd[12709]: conn=11 fd=14 closed (TLS negotiation failure) Nov 21 23:08:54 testsvr slapd[12709]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 21 23:08:54 testsvr slapd[12709]: daemon: epoll: listen=8 active_threads=0 tvp=zero Nov 21 23:08:54 testsvr slapd[12709]: daemon: activity on 1 descriptor Nov 21 23:08:54 testsvr slapd[12709]: daemon: activity on: Nov 21 23:08:54 testsvr slapd[12709]: Nov 21 23:08:54 testsvr slapd[12709]: daemon: epoll: listen=7 active_threads=0 tvp=zero Nov 21 23:08:54 testsvr slapd[12709]: daemon: epoll: listen=8 active_threads=0 tvp=zero

---- Not all who wander are lost.

| ---- ___o | chuck.keagle@boeing.com Chuck Keagle | ------- \ <, | Work: (425) 865-1488 Enterprise Servers: HPC | ----- ( )/ ( ) | Cell: (425) 417-3434

On Wed, 21 Nov 2007, Keagle, Chuck wrote:

I have yet to even change the error messages when trying:

# ldapsearch -x -Z -H ldap://testsvr.blv.boeing.com -b "" -s base 'objectclass=*' '+' '*' ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Looks to me like slapd is sending its cert, but either 1) it doesn't match the hostname in the URI (testsvr.blv.boeing.com), or 2) none of the CAs 'above' it are in the set of CAs trusted to ldapsearch.

So, what's the output of openssl x509 -text -noout -in /path/to/servers/cert/here.pem

? Does it show testsvr.blv.boeing.com either as a DNS X509v3 Subject Alternative Name or as the value of a CN attribute in the cert's subject? If not, there's (part of) your problem, as your cert MUST match the name in the URI used to locate the server. If that wasn't true, TLS/SSL would be easily attackable and therefore pointless.

...

#TLSCertificateFile /etc/ssl/servercerts/servercert.pem TLSCACertificatePath /etc/ssl/certs/ TLSCACertificateFile /etc/ssl/certs/ldapServer.pem #TLSCertificateKeyFile /etc/ssl/servercerts/serverkey.pem

Wait, so you're running the server without certificate or key files? How do you think that can possibly work?

...

##### # Database Configuration Parameters #####

#TLSCertificateFile /etc/openldap/servercert.pem #TLSCertificateKeyFile /etc/openldap/serverkey.pem

Another pair of these? What are they doing in the database config part of your slapd.conf? Don't you keep the directives grouped by function?

...

Here is /etc/openldap/ldap.conf

...

TLS_REQCERT allow #CBK Added for self-signed certificate

Well, this means that item #2 above (checking of CAs) can't be the issue, because the 'allow' setting bypasses that check.

(...rendering the TLS negotiation subject to an easy Man-in-the-Middle attack, of course...)

HOST testsvr.blv.boeing.com

Don't set this. The HOST and PORT settings should never be used. Indeed, this conflicts with the URI setting you also put in the file!

TLS_CACERT /etc/ssl/certs/ldapServer.pem

If that file is the server's self-signed cert, then you should not need the TLS_REQCERT option.

Philip Guenther

Keagle, Chuck skrev, on 22-11-2007 01:32:

I have yet to even change the error messages when trying:

# ldapsearch -x -Z -H ldap://testsvr.blv.boeing.com -b "" -s base 'objectclass=*' '+' '*' ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed ldap_result: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Can anyone point out what I have missed here?

You've been trying to knock down a brick wall with your head since before Saturday last week and to now seemingly got nowhere but bruised and battered. I should try a different approach, I'll give an example.

I don't know SLES at all, I run Red Hat systems. To me the whole concept of multiple hashed certs without proper names in a common folder is horrible. The concept of operating with server certs without them being signed by (an albeit self-generated) common CA cert is horrible. You'll se why below.

On my 4 RHEL5 servers that need certs for OL 2.3 and have been installed as upgrades in August last, I have done the following:

Designated one server as being the master, on which the CA cert for all of them was made, using the CA.sh utility included with RH's openssl 0.9.8b and installed the cert (named CA.pem) in /etc/certs/CA.

Edited /etc/pki/tls/openssl.cnf to reflect my site's true details and created a single servercert.pem and serverkey.pem (using the CA cert/key I'd created and ensuring the CN in the server cert is actually that of the machine as given in /etc/hosts and DNS and CA.sh) which is to be used for all services on the master. Did 'openssl rsa -in serverkey.pem.orig -out serverkey.pem' to get a "passwordless" key. For slapd installed these in /etc/certs/slapd with owner:group ldap and appropriate permissions.

All other services (e.g http, Postfix etc.) use the same serverkey and servercert, but in different subfolders, with different owners and permissions.

In all files needing any of these (thus also in slapd.conf and ldap.conf) put the paths in. TLS and SSL work on the master for all LDAP-base things needing it ;)

scp -p the necessary subfolders of /etc/CA and /etc/pki/tls/openssl.cnf to each other server that has to run slapd, edit onenssl.cnf to reflect the true CN and generate new servercert.pem and serverkey.pem (using the CA cert and key from the master server), make serverkey.pem "passwordless", install to the same folders as on the master. TLS and SSL work ;)

Because the RHL5 openssl directories are located differently from the RHAS4 same and on my FC6 test machine it took me 1/2 hour to make the master server's certs. I'd had much experience from RHAS4 and had botched up the cert thing by making a CA cert and server certs with far too short validities (accepting the default) for each server. Using different CA certs for each server meant I had to append the CA cert for each in /etc/certs/CA and meant replacing these on each server at least once in the two years the site was running RHAS4 and gave too much work. I wanted to avoid this for the future, so certs have validities till 2012. Making the server certs and keys for each other server cost me 10 minutes per server and I shall have no more work on certs until the site upgrades to RHEL6, or whatever it happens to be.

HTH, you don't *have* to do everything SuSE's way, just as I don't have to RH's way.

--Tonni