Hi,
A couple of quick questions about things that have been bugging me:
- If I import a server certificate and a CA certificate with pk12util
and change the trust attributes on the CA cert to "C,," - i.e.
that
it should be a trusted CA for server certificates - and then start
slapd I get:
[05/Jan/2006:17:21:57 +0000] conn=0 op=-1 fd=64 closed - No certificate
authority is trusted for SSL client authentication.
Which seems strange to me - I would have thought the CA certs in
nssckbi would be trusted for client auth?
- Unless /opt/fedora-ds/alias is owned by nobody:nobody you get
[05/Jan/2006:17:43:40 +0000] - SSL alert: Security Initialization: NSS
initialization failed (Netscape Portable Runtime error -8192 - An I/O error
occurred during security authorization.): path: /opt/fedora-ds/alias/, certdb
prefix: slapd-foo-, keydb prefix: slapd-foo-.
[05/Jan/2006:17:43:40 +0000] - ERROR: NSS Initialization Failed.
Couldn''t we not make the directory owned by nobody:nobody by
default in the RPM? root:root doesn''t seem like a useful default.
Cheers,
Mark.
Mark McLoughlin wrote:> Hi, > A couple of quick questions about things that have been bugging me: > > - If I import a server certificate and a CA certificate with pk12util > and change the trust attributes on the CA cert to "C,," - i.e. that > it should be a trusted CA for server certificates - and then start > slapd I get: > > [05/Jan/2006:17:21:57 +0000] conn=0 op=-1 fd=64 closed - No certificate authority is trusted for SSL client authentication. > > Which seems strange to me - I would have thought the CA certs in > nssckbi would be trusted for client auth?The C trust flag means that it is a trusted CA to issue server certs. For client certs you need the T flag as well. nssckbi doesn''t really come into play here. I believe that even if your CA is signed by another CA that is in libnssckbi but you don''t trust your CA to sign client certs, then any client certificates issued by your CA won''t be trusted. rob
Mark McLoughlin wrote:>Hi, > A couple of quick questions about things that have been bugging me: > > - If I import a server certificate and a CA certificate with pk12util > and change the trust attributes on the CA cert to "C,," - i.e. that > it should be a trusted CA for server certificates - and then start > slapd I get: > >[05/Jan/2006:17:21:57 +0000] conn=0 op=-1 fd=64 closed - No certificate authority is trusted for SSL client authentication. > > Which seems strange to me - I would have thought the CA certs in > nssckbi would be trusted for client auth? > >Hmm - not sure.> > - Unless /opt/fedora-ds/alias is owned by nobody:nobody you get > >[05/Jan/2006:17:43:40 +0000] - SSL alert: Security Initialization: NSS initialization failed (Netscape Portable Runtime error -8192 - An I/O error occurred during security authorization.): path: /opt/fedora-ds/alias/, certdb prefix: slapd-foo-, keydb prefix: slapd-foo-. >[05/Jan/2006:17:43:40 +0000] - ERROR: NSS Initialization Failed. > > Couldn''t we not make the directory owned by nobody:nobody by > default in the RPM? root:root doesn''t seem like a useful default. > >Yes, and it should be nobody:nobody - the setup script for FDS 1.0.1 should be setting that directory to be owned by nobody:nobody. Did you run setup after installing FDS 1.0.1? We''re currently revamping the RPM installation.>Cheers, >Mark. > >-- >Fedora-directory-users mailing list >Fedora-directory-users@redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-users > >
On Fri, 2006-01-06 at 07:57 -0700, Richard Megginson wrote:> > - Unless /opt/fedora-ds/alias is owned by nobody:nobody you get > > > >[05/Jan/2006:17:43:40 +0000] - SSL alert: Security Initialization: NSS initialization failed (Netscape Portable Runtime error -8192 - An I/O error occurred during security authorization.): path: /opt/fedora-ds/alias/, certdb prefix: slapd-foo-, keydb prefix: slapd-foo-. > >[05/Jan/2006:17:43:40 +0000] - ERROR: NSS Initialization Failed. > > > > Couldn''t we not make the directory owned by nobody:nobody by > > default in the RPM? root:root doesn''t seem like a useful default. > > > > > Yes, and it should be nobody:nobody - the setup script for FDS 1.0.1 > should be setting that directory to be owned by nobody:nobody. Did you > run setup after installing FDS 1.0.1?No, I''m not using the setup script.> We''re currently revamping the RPM installation.Excellent; is the work-in-progress available anywhere for people to poke at? Cheers, Mark.
Hi Rob, On Fri, 2006-01-06 at 09:21 -0500, Rob Crittenden wrote:> Mark McLoughlin wrote: > > Hi, > > A couple of quick questions about things that have been bugging me: > > > > - If I import a server certificate and a CA certificate with pk12util > > and change the trust attributes on the CA cert to "C,," - i.e. that > > it should be a trusted CA for server certificates - and then start > > slapd I get: > > > > [05/Jan/2006:17:21:57 +0000] conn=0 op=-1 fd=64 closed - No certificate authority is trusted for SSL client authentication. > > > > Which seems strange to me - I would have thought the CA certs in > > nssckbi would be trusted for client auth? > > The C trust flag means that it is a trusted CA to issue server certs. > For client certs you need the T flag as well.Right.> nssckbi doesn''t really come into play here. I believe that even if your > CA is signed by another CA that is in libnssckbi but you don''t trust > your CA to sign client certs, then any client certificates issued by > your CA won''t be trusted.Well, the point is that this CA won''t be issuing an client certificates ... only a server certificate. What appears to be happening is that NSS requires at least one CA certificate to be available in order to send a certificate request during the handshake. However, my CA certificate isn''t trusted for client auth and NSS isn''t aware of any other CAs for client auth, so it barfs. I find this puzzling because looking through the NSS code, it looks like the CA certificates from nssckbi should be used for client auth - e.g. the error suggests that if I make my CA trusted for client auth, it will be the *only* CA used for client auth and that the root CAs will be ignored? Cheers, Mark.
Mark McLoughlin wrote:>On Fri, 2006-01-06 at 07:57 -0700, Richard Megginson wrote: > > > >>> - Unless /opt/fedora-ds/alias is owned by nobody:nobody you get >>> >>>[05/Jan/2006:17:43:40 +0000] - SSL alert: Security Initialization: NSS initialization failed (Netscape Portable Runtime error -8192 - An I/O error occurred during security authorization.): path: /opt/fedora-ds/alias/, certdb prefix: slapd-foo-, keydb prefix: slapd-foo-. >>>[05/Jan/2006:17:43:40 +0000] - ERROR: NSS Initialization Failed. >>> >>> Couldn''t we not make the directory owned by nobody:nobody by >>> default in the RPM? root:root doesn''t seem like a useful default. >>> >>> >>> >>> >>Yes, and it should be nobody:nobody - the setup script for FDS 1.0.1 >>should be setting that directory to be owned by nobody:nobody. Did you >>run setup after installing FDS 1.0.1? >> >> > > No, I''m not using the setup script. > >Ah, that explains it.> > >>We''re currently revamping the RPM installation. >> >> > > Excellent; is the work-in-progress available anywhere for people to >poke at? > >No, not yet. We''re still climbing the mountain of dependent components - nspr, nss, svrcore, ldapsdk, ldapjdk, etc. etc.>Cheers, >Mark. > >-- >Fedora-directory-users mailing list >Fedora-directory-users@redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-users > >
I was just wondering what the community thoughts are on the subject of root accounts in LDAP vs. local. Some SAs in the company insist on keeping root passwords local in case of LDAP outage, saying that root is too critical to be handed over to FDS. Personally, I think it''s no big deal. We have it local right now and every time an SA or a mgr quits, we''ve to login to every unix/linux box and change root''s password which is a real pain. What are your thoughts on the subject? Are there some accounts that you insist on keeping local or is that line of thinking anachronistic? Thank you. __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Mark McLoughlin wrote:> Hi Rob, > > On Fri, 2006-01-06 at 09:21 -0500, Rob Crittenden wrote: > >>Mark McLoughlin wrote: >> >>>Hi, >>> A couple of quick questions about things that have been bugging me: >>> >>> - If I import a server certificate and a CA certificate with pk12util >>> and change the trust attributes on the CA cert to "C,," - i.e. that >>> it should be a trusted CA for server certificates - and then start >>> slapd I get: >>> >>>[05/Jan/2006:17:21:57 +0000] conn=0 op=-1 fd=64 closed - No certificate authority is trusted for SSL client authentication. >>> >>> Which seems strange to me - I would have thought the CA certs in >>> nssckbi would be trusted for client auth? >> >>The C trust flag means that it is a trusted CA to issue server certs. >>For client certs you need the T flag as well. > > > Right. > > >>nssckbi doesn''t really come into play here. I believe that even if your >>CA is signed by another CA that is in libnssckbi but you don''t trust >>your CA to sign client certs, then any client certificates issued by >>your CA won''t be trusted. > > > Well, the point is that this CA won''t be issuing an client > certificates ... only a server certificate. > > What appears to be happening is that NSS requires at least one CA > certificate to be available in order to send a certificate request > during the handshake. However, my CA certificate isn''t trusted for > client auth and NSS isn''t aware of any other CAs for client auth, so it > barfs. > > I find this puzzling because looking through the NSS code, it looks > like the CA certificates from nssckbi should be used for client auth - > e.g. the error suggests that if I make my CA trusted for client auth, it > will be the *only* CA used for client auth and that the root CAs will be > ignored?The question is: Do you want to do client certificate authentication? If not then you should be able to disable client auth in the directory server and this message should go away. I''m not a FDS developer so I can''t really say how one would do this configuration. As for the trust issue, this goes a bit beyond my knowledge. This would be a good question for the NSS guys in the netscape.public.mozilla.crypto newsgroup (on nntp://news.mozilla.org). rob> > Cheers, > Mark. > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users
On Fri, 2006-01-06 at 10:47 -0500, Rob Crittenden wrote:> Mark McLoughlin wrote:> > What appears to be happening is that NSS requires at least one CA > > certificate to be available in order to send a certificate request > > during the handshake. However, my CA certificate isn''t trusted for > > client auth and NSS isn''t aware of any other CAs for client auth, so it > > barfs. > > > > I find this puzzling because looking through the NSS code, it looks > > like the CA certificates from nssckbi should be used for client auth - > > e.g. the error suggests that if I make my CA trusted for client auth, it > > will be the *only* CA used for client auth and that the root CAs will be > > ignored? > > The question is: Do you want to do client certificate authentication? If > not then you should be able to disable client auth in the directory > server and this message should go away. I''m not a FDS developer so I > can''t really say how one would do this configuration.Yep, if you disable client auth, no attempt is made to send a certificate request during the handshake and you don''t get any error. (To disable it you seem to have to set both "nsslapd-sslclientauth" on "cn=config" and "nsSSLClientAuth" on "cn=encryption,cn=config")> As for the trust issue, this goes a bit beyond my knowledge. This would > be a good question for the NSS guys in the > netscape.public.mozilla.crypto newsgroup (on nntp://news.mozilla.org).Okay, thanks for your help. Cheers, Mark.
David Hollis
2006-Jan-06 18:40 UTC
Re: [Fedora-directory-users] putting root account in FDS
On Fri, 2006-01-06 at 07:31 -0800, Susan wrote:> I was just wondering what the community thoughts are on the subject of root accounts in LDAP vs. > local. Some SAs in the company insist on keeping root passwords local in case of LDAP outage, > saying that root is too critical to be handed over to FDS. Personally, I think it''s no big deal. > We have it local right now and every time an SA or a mgr quits, we''ve to login to every unix/linux > box and change root''s password which is a real pain. > > What are your thoughts on the subject? Are there some accounts that you insist on keeping local > or is that line of thinking anachronistic?Keeping root local does make sense. Giving every SA the root password doesn''t. Use something like sudo to restrict and log SA administrative tasks. They then use their own password to switch up to root privs to perform a task, it gets logged, etc. When they leave, their account gets disabled and they no longer have any way to get to root. You still need to ensure that they don''t do bad stuff like create another acct with UID 0 or something that gives them a backdoor.
Mike Jackson
2006-Jan-07 11:28 UTC
Re: [Fedora-directory-users] putting root account in FDS
Susan wrote:> I was just wondering what the community thoughts are on the subject of root accounts in LDAP vs. > local. Some SAs in the company insist on keeping root passwords local in case of LDAP outage, > saying that root is too critical to be handed over to FDS. Personally, I think it''s no big deal. > We have it local right now and every time an SA or a mgr quits, we''ve to login to every unix/linux > box and change root''s password which is a real pain. > > What are your thoughts on the subject? Are there some accounts that you insist on keeping local > or is that line of thinking anachronistic?How are you supposed to log into your machine to restart a crashed LDAP service, if the root account (and all other accounts) is only stored in LDAP? Chicken or egg? On some boxes, you might need to give the root password to someone. On other boxes which are more sensitive, you don''t want to give the root password to anyone. From a security perspective, having a single, enterprise-wide, root password is foolhardy and puts you down to the same security level as a windows "domain". To consider putting the root account into LDAP is basically not a stupid question, because you may have been shortsighted by the perceived benefits (ease of management). To put it there, however, is not a very good idea, for the reasons outlined above. -- mike
Edward Fochler
2006-Jan-07 20:20 UTC
Re: [Fedora-directory-users] putting root account in FDS
We have root local on the boxes, but are locking it out from ssh. Admins are being weened off of root and are allowed to ssh and sudo if they are in the right groups in ldap. I also put in a local ssh and sudo capable non-root local account on the boes I manage to deal with network outages and misonfigurations. ssh brute force and a known-name god account like root are just a nightmare that I intend to stay far far away from. I do have a dummy, non-modifiable no password root entry in my username table so that if ldap becomes compromised, that''s one avenue of attack that will be that much harder to exploit, and easy to detect. The problem is a good one, and I like the solution I''m using currently, which is partially inspired by the default setup of Mac OS X. No known (default) account names with login access. ED. On 2006, Jan 7, at 6:28 AM, Mike Jackson wrote:> Susan wrote: >> I was just wondering what the community thoughts are on the >> subject of root accounts in LDAP vs. >> local. Some SAs in the company insist on keeping root passwords >> local in case of LDAP outage, >> saying that root is too critical to be handed over to FDS. >> Personally, I think it''s no big deal. We have it local right now >> and every time an SA or a mgr quits, we''ve to login to every unix/ >> linux >> box and change root''s password which is a real pain. >> What are your thoughts on the subject? Are there some accounts >> that you insist on keeping local >> or is that line of thinking anachronistic? > > How are you supposed to log into your machine to restart a crashed > LDAP service, if the root account (and all other accounts) is only > stored in LDAP? Chicken or egg? > > On some boxes, you might need to give the root password to someone. > On other boxes which are more sensitive, you don''t want to give the > root password to anyone. From a security perspective, having a > single, enterprise-wide, root password is foolhardy and puts you > down to the same security level as a windows "domain". > > To consider putting the root account into LDAP is basically not a > stupid question, because you may have been shortsighted by the > perceived benefits (ease of management). To put it there, however, > is not a very good idea, for the reasons outlined above. > > > -- > mike > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users