On Tue, 2009-01-20 at 08:43 -0700, Rich Megginson wrote:
John A. Sullivan III wrote:
> On Sat, 2009-01-17 at 19:59 -0500, John A. Sullivan III wrote:
>
>> Hello, all. We are working on implementing SSL on our directory server.
>> Our test environment is using Centos using console framework 1.1.1 and
>> ds centos-ds-8.0.0-1.4.el5.centos.4. When we attempt to login to
>> centos-idm-console, we receive an error that the certificate this server
>> presents is either untrusted or unknown. When we view the cert, the
>> note under details says "Untrusted issuer". However, if we look in
>> Manage Certificates for the Administration Server (I assume the console
>> is logging into the Administration Server but the same is true for the
>> Directory Server), we see the CA cert as trusted and see the certificate
>> chain. Everything looks correct. Why is the console not trusting the
>> CA cert? Is it looking for it someplace else? If so, where?
>>
>> More details:
>> I'm assuming the problem is the CA cert. The admin server cert details
>> are:
>> cn=ldap01admin.ssiservices.biz
>> There are DNS entries in subjAltName of:
>> ldap01.ssiservices.biz
>> ldap01
>> ldap01admin
>> and there is an IP address entry.
>>
>> I get the same problem connecting to
>>
https://ldap01admin.ssiservices.biz:9830 as
>>
https://ldap01.ssiservices.biz:9830
>>
>>
> On a lark, I took a look in my home directory and, sure enough, found
> a .centos-idm-console directory. I entered it and issue the following
> command to import the CA cert into the individual user's database:
>
> certutil -A -d . -n "CA certificate" -t "CT,," -a
> -i /etc/dirsrv/admin-serv/SSICA.pem
>
> It all works now. Perhaps I overlooked it but I did not see that step
> in the documentation.
>
Please file a doc bug.
The way it should work is if there is no CA cert, you should get a
dialog asking you if you want to temporarily accept the connection. Is
it possible there was an old CA cert in ~/.centos-idm-console/cert8.db?
Oh, that is
the way it was working. I was just expecting it to work
without having to manually accept the cert. The key was telling the
user to trust the CA. It makes perfect sense now that I understand what
is happening - of course the user application is not using the CA trust
already established within the directory server to authenticate to the
directory server! Thus it needs to trust the CA independently.
> I've also noticed that the manage certificate dialogs
reverse the OU and
> O fields on the details page.
>
This has been fixed and the fix will be in the next release.
> Finally, it appears idm-console can use the entries in the subjAltName,
> i.e., I can login using both ldap01 and ldap01admin for the host but it
> does not like the IP field, i.e., I cannot login to
>
https://10.1.1.1:9830 without generating a cert warning - John
>
I'm not sure if IP addresses are supposed to play well with
subjectAltName - do other software packages work like this? I'm not
sure what the standards say about this.
Web browsers will indeed accept the IP
values of the subjAltName to
identify the entity (at least Firefox does and I believe the spec (I
don't recall the RFC number) does call for such behavior). It appears
idm-console has not been so coded.
--
Fedora-directory-users mailing list
Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users --
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society