4:33 p.m.
Hello,
I'm attempting to configure 389 DS v1.2.9.14 on RHEL 6.2 to use TLS with
a certificate issued by a CA. I was previously able to configure TLS
support using a self-signed certificate on a test system using 389 DS
1.2.8.2, but I am not having any success with the CA-issued certificate.
Using the GUI is not an option, but I have used certutil to create the
key/certificate databases, generate a CSR, and subsequently install the
CA certificate and the signed SSL certificate.
The server has been configured to use the certificate and the LDAPS
listener has been enabled. The server starts up without complaint and
the error log shows that it is listening on both port 389 and 636.
However, attempts to connect to the LDAPS port fail:
ds1.imorgan % openssl s_client -connect localhost:636
CONNECTED(00000003)
140218505807688:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 113 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
ds1.imorgan %
Unfortunately, there do not appear to be any log messages which indicate
the source of the problem. I've played with the trust flags for the
certificate and have even tried re-importing it; all to no avail.
Any help would be appreciated.
Thanks
--
Iain Morgan
4:41 p.m.
Review the 389 DS errors log file, and the config, it seem like TLS did
not start.
Use the console UI a first time to review the working configuration,
just for a test, and compare with the manual settings.
M.
On 01/09/2012 02:33 PM, Iain Morgan wrote:
Hello,
I'm attempting to configure 389 DS v1.2.9.14 on RHEL 6.2 to use TLS with
a certificate issued by a CA. I was previously able to configure TLS
support using a self-signed certificate on a test system using 389 DS
1.2.8.2, but I am not having any success with the CA-issued certificate.
Using the GUI is not an option, but I have used certutil to create the
key/certificate databases, generate a CSR, and subsequently install the
CA certificate and the signed SSL certificate.
The server has been configured to use the certificate and the LDAPS
listener has been enabled. The server starts up without complaint and
the error log shows that it is listening on both port 389 and 636.
However, attempts to connect to the LDAPS port fail:
ds1.imorgan % openssl s_client -connect localhost:636
CONNECTED(00000003)
140218505807688:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 113 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
ds1.imorgan %
Unfortunately, there do not appear to be any log messages which indicate
the source of the problem. I've played with the trust flags for the
certificate and have even tried re-importing it; all to no avail.
Any help would be appreciated.
Thanks
4:59 p.m.
The error log does not report any issues. It indicates that ns-slapd is
listening on both port 389 and 636. and it does not indicate any errors
at connection time.
ds1.root # tail errors
[09/Jan/2012:13:57:28 -0800] - slapd shutting down - signaling operation
threads
[09/Jan/2012:13:57:28 -0800] - slapd shutting down - waiting for 15
threads to terminate
[09/Jan/2012:13:57:28 -0800] - slapd shutting down - closing down
internal subsystems and plugins
[09/Jan/2012:13:57:28 -0800] - Waiting for 4 database threads to stop
[09/Jan/2012:13:57:28 -0800] - All database threads now stopped
[09/Jan/2012:13:57:28 -0800] - slapd stopped.
[09/Jan/2012:13:57:29 -0800] - 389-Directory/1.2.9.14 B2011.312.195
starting up
[09/Jan/2012:13:57:29 -0800] - slapd started. Listening on Loopback
port 389 for LDAP requests
[09/Jan/2012:13:57:29 -0800] - Listening on Loopback port 636 for LDAPS
requests
[09/Jan/2012:13:57:29 -0800] - Listening on /var/run/slapd-ds1.socket
for LDAPI requests
ds1.root #
I've already compared the dse.ldif from the problem system to the
dse.ldif from the working system which uses a self-signed certificate.
The only difference of note was the addition of the
nsslapd-validate-cert attribute in the problem server. Incidentally,
changing the value of that attribute from "warn" to "on" or
"off" made
no difference.
And, as mentioned in the original post, using the console GUI is not an
option.
On Mon, Jan 09, 2012 at 16:41:36 -0600, Marc Sauton wrote:
Review the 389 DS errors log file, and the config, it seem like TLS
did
not start.
Use the console UI a first time to review the working configuration,
just for a test, and compare with the manual settings.
M.
On 01/09/2012 02:33 PM, Iain Morgan wrote:
> Hello,
>
> I'm attempting to configure 389 DS v1.2.9.14 on RHEL 6.2 to use TLS with
> a certificate issued by a CA. I was previously able to configure TLS
> support using a self-signed certificate on a test system using 389 DS
> 1.2.8.2, but I am not having any success with the CA-issued certificate.
>
> Using the GUI is not an option, but I have used certutil to create the
> key/certificate databases, generate a CSR, and subsequently install the
> CA certificate and the signed SSL certificate.
>
> The server has been configured to use the certificate and the LDAPS
> listener has been enabled. The server starts up without complaint and
> the error log shows that it is listening on both port 389 and 636.
> However, attempts to connect to the LDAPS port fail:
>
> ds1.imorgan % openssl s_client -connect localhost:636
> CONNECTED(00000003)
> 140218505807688:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:184:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 113 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> ---
> ds1.imorgan %
>
> Unfortunately, there do not appear to be any log messages which indicate
> the source of the problem. I've played with the trust flags for the
> certificate and have even tried re-importing it; all to no avail.
>
> Any help would be appreciated.
>
> Thanks
>
--
Iain Morgan
4:59 p.m.
On 01/09/2012 03:59 PM, Iain Morgan wrote:
The error log does not report any issues. It indicates that ns-slapd
is
listening on both port 389 and 636. and it does not indicate any errors
at connection time.
ds1.root # tail errors
[09/Jan/2012:13:57:28 -0800] - slapd shutting down - signaling operation
threads
[09/Jan/2012:13:57:28 -0800] - slapd shutting down - waiting for 15
threads to terminate
[09/Jan/2012:13:57:28 -0800] - slapd shutting down - closing down
internal subsystems and plugins
[09/Jan/2012:13:57:28 -0800] - Waiting for 4 database threads to stop
[09/Jan/2012:13:57:28 -0800] - All database threads now stopped
[09/Jan/2012:13:57:28 -0800] - slapd stopped.
[09/Jan/2012:13:57:29 -0800] - 389-Directory/1.2.9.14 B2011.312.195
starting up
[09/Jan/2012:13:57:29 -0800] - slapd started. Listening on Loopback
port 389 for LDAP requests
[09/Jan/2012:13:57:29 -0800] - Listening on Loopback port 636 for LDAPS
requests
[09/Jan/2012:13:57:29 -0800] - Listening on /var/run/slapd-ds1.socket
for LDAPI requests
ds1.root #
I've already compared the dse.ldif from the problem system to the
dse.ldif from the working system which uses a self-signed certificate.
The only difference of note was the addition of the
nsslapd-validate-cert attribute in the problem server. Incidentally,
changing the value of that attribute from "warn" to "on" or
"off" made
no difference.
And, as mentioned in the original post, using the console GUI is not an
option.
What happens if you specify the -CAfile filename arguments to openssl
s_client?
On Mon, Jan 09, 2012 at 16:41:36 -0600, Marc Sauton wrote:
> Review the 389 DS errors log file, and the config, it seem like TLS did
> not start.
> Use the console UI a first time to review the working configuration,
> just for a test, and compare with the manual settings.
> M.
>
> On 01/09/2012 02:33 PM, Iain Morgan wrote:
>> Hello,
>>
>> I'm attempting to configure 389 DS v1.2.9.14 on RHEL 6.2 to use TLS with
>> a certificate issued by a CA. I was previously able to configure TLS
>> support using a self-signed certificate on a test system using 389 DS
>> 1.2.8.2, but I am not having any success with the CA-issued certificate.
>>
>> Using the GUI is not an option, but I have used certutil to create the
>> key/certificate databases, generate a CSR, and subsequently install the
>> CA certificate and the signed SSL certificate.
>>
>> The server has been configured to use the certificate and the LDAPS
>> listener has been enabled. The server starts up without complaint and
>> the error log shows that it is listening on both port 389 and 636.
>> However, attempts to connect to the LDAPS port fail:
>>
>> ds1.imorgan % openssl s_client -connect localhost:636
>> CONNECTED(00000003)
>> 140218505807688:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>> failure:s23_lib.c:184:
>> ---
>> no peer certificate available
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 0 bytes and written 113 bytes
>> ---
>> New, (NONE), Cipher is (NONE)
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> ---
>> ds1.imorgan %
>>
>> Unfortunately, there do not appear to be any log messages which indicate
>> the source of the problem. I've played with the trust flags for the
>> certificate and have even tried re-importing it; all to no avail.
>>
>> Any help would be appreciated.
>>
>> Thanks
>>
5:11 p.m.
On Mon, Jan 09, 2012 at 16:59:33 -0600, Rich Megginson wrote:
On 01/09/2012 03:59 PM, Iain Morgan wrote:
> The error log does not report any issues. It indicates that ns-slapd is
> listening on both port 389 and 636. and it does not indicate any errors
> at connection time.
>
> ds1.root # tail errors
> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - signaling operation
> threads
> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - waiting for 15
> threads to terminate
> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - closing down
> internal subsystems and plugins
> [09/Jan/2012:13:57:28 -0800] - Waiting for 4 database threads to stop
> [09/Jan/2012:13:57:28 -0800] - All database threads now stopped
> [09/Jan/2012:13:57:28 -0800] - slapd stopped.
> [09/Jan/2012:13:57:29 -0800] - 389-Directory/1.2.9.14 B2011.312.195
> starting up
> [09/Jan/2012:13:57:29 -0800] - slapd started. Listening on Loopback
> port 389 for LDAP requests
> [09/Jan/2012:13:57:29 -0800] - Listening on Loopback port 636 for LDAPS
> requests
> [09/Jan/2012:13:57:29 -0800] - Listening on /var/run/slapd-ds1.socket
> for LDAPI requests
> ds1.root #
>
> I've already compared the dse.ldif from the problem system to the
> dse.ldif from the working system which uses a self-signed certificate.
> The only difference of note was the addition of the
> nsslapd-validate-cert attribute in the problem server. Incidentally,
> changing the value of that attribute from "warn" to "on" or
"off" made
> no difference.
>
> And, as mentioned in the original post, using the console GUI is not an
> option.
What happens if you specify the -CAfile filename arguments to openssl
I get the same behaviour with -CAfile set.
s_client?
> On Mon, Jan 09, 2012 at 16:41:36 -0600, Marc Sauton wrote:
>> Review the 389 DS errors log file, and the config, it seem like TLS did
>> not start.
>> Use the console UI a first time to review the working configuration,
>> just for a test, and compare with the manual settings.
>> M.
>>
>> On 01/09/2012 02:33 PM, Iain Morgan wrote:
>>> Hello,
>>>
>>> I'm attempting to configure 389 DS v1.2.9.14 on RHEL 6.2 to use TLS
with
>>> a certificate issued by a CA. I was previously able to configure TLS
>>> support using a self-signed certificate on a test system using 389 DS
>>> 1.2.8.2, but I am not having any success with the CA-issued certificate.
>>>
>>> Using the GUI is not an option, but I have used certutil to create the
>>> key/certificate databases, generate a CSR, and subsequently install the
>>> CA certificate and the signed SSL certificate.
>>>
>>> The server has been configured to use the certificate and the LDAPS
>>> listener has been enabled. The server starts up without complaint and
>>> the error log shows that it is listening on both port 389 and 636.
>>> However, attempts to connect to the LDAPS port fail:
>>>
>>> ds1.imorgan % openssl s_client -connect localhost:636
>>> CONNECTED(00000003)
>>> 140218505807688:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>>> failure:s23_lib.c:184:
>>> ---
>>> no peer certificate available
>>> ---
>>> No client certificate CA names sent
>>> ---
>>> SSL handshake has read 0 bytes and written 113 bytes
>>> ---
>>> New, (NONE), Cipher is (NONE)
>>> Secure Renegotiation IS NOT supported
>>> Compression: NONE
>>> Expansion: NONE
>>> ---
>>> ds1.imorgan %
>>>
>>> Unfortunately, there do not appear to be any log messages which indicate
>>> the source of the problem. I've played with the trust flags for the
>>> certificate and have even tried re-importing it; all to no avail.
>>>
>>> Any help would be appreciated.
>>>
>>> Thanks
>>>
--
Iain Morgan
5:18 p.m.
On 01/09/2012 04:11 PM, Iain Morgan wrote:
On Mon, Jan 09, 2012 at 16:59:33 -0600, Rich Megginson wrote:
> On 01/09/2012 03:59 PM, Iain Morgan wrote:
>> The error log does not report any issues. It indicates that ns-slapd is
>> listening on both port 389 and 636. and it does not indicate any errors
>> at connection time.
>>
>> ds1.root # tail errors
>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - signaling operation
>> threads
>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - waiting for 15
>> threads to terminate
>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - closing down
>> internal subsystems and plugins
>> [09/Jan/2012:13:57:28 -0800] - Waiting for 4 database threads to stop
>> [09/Jan/2012:13:57:28 -0800] - All database threads now stopped
>> [09/Jan/2012:13:57:28 -0800] - slapd stopped.
>> [09/Jan/2012:13:57:29 -0800] - 389-Directory/1.2.9.14 B2011.312.195
>> starting up
>> [09/Jan/2012:13:57:29 -0800] - slapd started. Listening on Loopback
>> port 389 for LDAP requests
>> [09/Jan/2012:13:57:29 -0800] - Listening on Loopback port 636 for LDAPS
>> requests
>> [09/Jan/2012:13:57:29 -0800] - Listening on /var/run/slapd-ds1.socket
>> for LDAPI requests
>> ds1.root #
>>
>> I've already compared the dse.ldif from the problem system to the
>> dse.ldif from the working system which uses a self-signed certificate.
>> The only difference of note was the addition of the
>> nsslapd-validate-cert attribute in the problem server. Incidentally,
>> changing the value of that attribute from "warn" to "on" or
"off" made
>> no difference.
>>
>> And, as mentioned in the original post, using the console GUI is not an
>> option.
> What happens if you specify the -CAfile filename arguments to openssl
I get the same behaviour with -CAfile set.
ok - try this
openssl s_client -showcerts -debug -connect localhost:636
remove/obscure any sensitive information in the output, paste it to
fpaste.org, and post the link here
> s_client?
>> On Mon, Jan 09, 2012 at 16:41:36 -0600, Marc Sauton wrote:
>>> Review the 389 DS errors log file, and the config, it seem like TLS did
>>> not start.
>>> Use the console UI a first time to review the working configuration,
>>> just for a test, and compare with the manual settings.
>>> M.
>>>
>>> On 01/09/2012 02:33 PM, Iain Morgan wrote:
>>>> Hello,
>>>>
>>>> I'm attempting to configure 389 DS v1.2.9.14 on RHEL 6.2 to use TLS
with
>>>> a certificate issued by a CA. I was previously able to configure TLS
>>>> support using a self-signed certificate on a test system using 389 DS
>>>> 1.2.8.2, but I am not having any success with the CA-issued certificate.
>>>>
>>>> Using the GUI is not an option, but I have used certutil to create the
>>>> key/certificate databases, generate a CSR, and subsequently install the
>>>> CA certificate and the signed SSL certificate.
>>>>
>>>> The server has been configured to use the certificate and the LDAPS
>>>> listener has been enabled. The server starts up without complaint and
>>>> the error log shows that it is listening on both port 389 and 636.
>>>> However, attempts to connect to the LDAPS port fail:
>>>>
>>>> ds1.imorgan % openssl s_client -connect localhost:636
>>>> CONNECTED(00000003)
>>>> 140218505807688:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>>>> failure:s23_lib.c:184:
>>>> ---
>>>> no peer certificate available
>>>> ---
>>>> No client certificate CA names sent
>>>> ---
>>>> SSL handshake has read 0 bytes and written 113 bytes
>>>> ---
>>>> New, (NONE), Cipher is (NONE)
>>>> Secure Renegotiation IS NOT supported
>>>> Compression: NONE
>>>> Expansion: NONE
>>>> ---
>>>> ds1.imorgan %
>>>>
>>>> Unfortunately, there do not appear to be any log messages which indicate
>>>> the source of the problem. I've played with the trust flags for the
>>>> certificate and have even tried re-importing it; all to no avail.
>>>>
>>>> Any help would be appreciated.
>>>>
>>>> Thanks
>>>>
5:39 p.m.
On Mon, Jan 09, 2012 at 17:18:30 -0600, Rich Megginson wrote:
On 01/09/2012 04:11 PM, Iain Morgan wrote:
> On Mon, Jan 09, 2012 at 16:59:33 -0600, Rich Megginson wrote:
>> On 01/09/2012 03:59 PM, Iain Morgan wrote:
>>> The error log does not report any issues. It indicates that ns-slapd is
>>> listening on both port 389 and 636. and it does not indicate any errors
>>> at connection time.
>>>
>>> ds1.root # tail errors
>>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - signaling operation
>>> threads
>>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - waiting for 15
>>> threads to terminate
>>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - closing down
>>> internal subsystems and plugins
>>> [09/Jan/2012:13:57:28 -0800] - Waiting for 4 database threads to stop
>>> [09/Jan/2012:13:57:28 -0800] - All database threads now stopped
>>> [09/Jan/2012:13:57:28 -0800] - slapd stopped.
>>> [09/Jan/2012:13:57:29 -0800] - 389-Directory/1.2.9.14 B2011.312.195
>>> starting up
>>> [09/Jan/2012:13:57:29 -0800] - slapd started. Listening on Loopback
>>> port 389 for LDAP requests
>>> [09/Jan/2012:13:57:29 -0800] - Listening on Loopback port 636 for LDAPS
>>> requests
>>> [09/Jan/2012:13:57:29 -0800] - Listening on /var/run/slapd-ds1.socket
>>> for LDAPI requests
>>> ds1.root #
>>>
>>> I've already compared the dse.ldif from the problem system to the
>>> dse.ldif from the working system which uses a self-signed certificate.
>>> The only difference of note was the addition of the
>>> nsslapd-validate-cert attribute in the problem server. Incidentally,
>>> changing the value of that attribute from "warn" to "on"
or "off" made
>>> no difference.
>>>
>>> And, as mentioned in the original post, using the console GUI is not an
>>> option.
>> What happens if you specify the -CAfile filename arguments to openssl
> I get the same behaviour with -CAfile set.
ok - try this
openssl s_client -showcerts -debug -connect localhost:636
remove/obscure any sensitive information in the output, paste it to
fpaste.org, and post the link here
Actually, the output is short enough that I might as well post it
inline:
ds1.imorgan % openssl s_client -showcerts -debug -connect localhost:636
CONNECTED(00000003)
write to 0x1d6e090 [0x1e0d8c0] (113 bytes => 113 (0x71))
0000 - 16 03 01 00 6c 01 00 00-68 03 01 4f 0b 78 fa 9c
....l...h..O.x..
0010 - 87 e5 f9 2f fa 40 6a 63-8b a7 74 23 5e b3 ac 8f
.../.@jc..t#^...
0020 - 53 20 d3 f0 fe 3c 9d 68-57 3f 47 00 00 3a 00 39 S
...<.hW?G..:.9
0030 - 00 38 00 88 00 87 00 35-00 84 00 16 00 13 00 0a
.8.....5........
0040 - 00 33 00 32 00 9a 00 99-00 45 00 44 00 2f 00 96
.3.2.....E.D./..
0050 - 00 41 00 05 00 04 00 15-00 12 00 09 00 14 00 11
.A..............
0060 - 00 08 00 06 00 03 00 ff-02 01 00 00 04 00 23 ..............#
0071 - <SPACES/NULS>
read from 0x1d6e090 [0x1e12e20] (7 bytes => 0 (0x0))
140434478798664:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 113 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
I can also post to fpast.org if that would be more convenient.
>> s_client?
>>> On Mon, Jan 09, 2012 at 16:41:36 -0600, Marc Sauton wrote:
>>>> Review the 389 DS errors log file, and the config, it seem like TLS did
>>>> not start.
>>>> Use the console UI a first time to review the working configuration,
>>>> just for a test, and compare with the manual settings.
>>>> M.
>>>>
>>>> On 01/09/2012 02:33 PM, Iain Morgan wrote:
>>>>> Hello,
>>>>>
>>>>> I'm attempting to configure 389 DS v1.2.9.14 on RHEL 6.2 to use
TLS with
>>>>> a certificate issued by a CA. I was previously able to configure
TLS
>>>>> support using a self-signed certificate on a test system using 389
DS
>>>>> 1.2.8.2, but I am not having any success with the CA-issued
certificate.
>>>>>
>>>>> Using the GUI is not an option, but I have used certutil to create
the
>>>>> key/certificate databases, generate a CSR, and subsequently install
the
>>>>> CA certificate and the signed SSL certificate.
>>>>>
>>>>> The server has been configured to use the certificate and the LDAPS
>>>>> listener has been enabled. The server starts up without complaint
and
>>>>> the error log shows that it is listening on both port 389 and 636.
>>>>> However, attempts to connect to the LDAPS port fail:
>>>>>
>>>>> ds1.imorgan % openssl s_client -connect localhost:636
>>>>> CONNECTED(00000003)
>>>>> 140218505807688:error:140790E5:SSL routines:SSL23_WRITE:ssl
handshake
>>>>> failure:s23_lib.c:184:
>>>>> ---
>>>>> no peer certificate available
>>>>> ---
>>>>> No client certificate CA names sent
>>>>> ---
>>>>> SSL handshake has read 0 bytes and written 113 bytes
>>>>> ---
>>>>> New, (NONE), Cipher is (NONE)
>>>>> Secure Renegotiation IS NOT supported
>>>>> Compression: NONE
>>>>> Expansion: NONE
>>>>> ---
>>>>> ds1.imorgan %
>>>>>
>>>>> Unfortunately, there do not appear to be any log messages which
indicate
>>>>> the source of the problem. I've played with the trust flags for
the
>>>>> certificate and have even tried re-importing it; all to no avail.
>>>>>
>>>>> Any help would be appreciated.
>>>>>
>>>>> Thanks
>>>>>
--
Iain Morgan
5:47 p.m.
On 01/09/2012 04:39 PM, Iain Morgan wrote:
On Mon, Jan 09, 2012 at 17:18:30 -0600, Rich Megginson wrote:
> On 01/09/2012 04:11 PM, Iain Morgan wrote:
>> On Mon, Jan 09, 2012 at 16:59:33 -0600, Rich Megginson wrote:
>>> On 01/09/2012 03:59 PM, Iain Morgan wrote:
>>>> The error log does not report any issues. It indicates that ns-slapd is
>>>> listening on both port 389 and 636. and it does not indicate any errors
>>>> at connection time.
>>>>
>>>> ds1.root # tail errors
>>>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - signaling operation
>>>> threads
>>>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - waiting for 15
>>>> threads to terminate
>>>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - closing down
>>>> internal subsystems and plugins
>>>> [09/Jan/2012:13:57:28 -0800] - Waiting for 4 database threads to stop
>>>> [09/Jan/2012:13:57:28 -0800] - All database threads now stopped
>>>> [09/Jan/2012:13:57:28 -0800] - slapd stopped.
>>>> [09/Jan/2012:13:57:29 -0800] - 389-Directory/1.2.9.14 B2011.312.195
>>>> starting up
>>>> [09/Jan/2012:13:57:29 -0800] - slapd started. Listening on Loopback
>>>> port 389 for LDAP requests
>>>> [09/Jan/2012:13:57:29 -0800] - Listening on Loopback port 636 for LDAPS
>>>> requests
>>>> [09/Jan/2012:13:57:29 -0800] - Listening on /var/run/slapd-ds1.socket
>>>> for LDAPI requests
>>>> ds1.root #
>>>>
>>>> I've already compared the dse.ldif from the problem system to the
>>>> dse.ldif from the working system which uses a self-signed certificate.
>>>> The only difference of note was the addition of the
>>>> nsslapd-validate-cert attribute in the problem server. Incidentally,
>>>> changing the value of that attribute from "warn" to
"on" or "off" made
>>>> no difference.
>>>>
>>>> And, as mentioned in the original post, using the console GUI is not an
>>>> option.
>>> What happens if you specify the -CAfile filename arguments to openssl
>> I get the same behaviour with -CAfile set.
> ok - try this
>
> openssl s_client -showcerts -debug -connect localhost:636
>
> remove/obscure any sensitive information in the output, paste it to
> fpaste.org, and post the link here
Actually, the output is short enough that I might as well post it
inline:
ds1.imorgan % openssl s_client -showcerts -debug -connect localhost:636
CONNECTED(00000003)
write to 0x1d6e090 [0x1e0d8c0] (113 bytes => 113 (0x71))
0000 - 16 03 01 00 6c 01 00 00-68 03 01 4f 0b 78 fa 9c
....l...h..O.x..
0010 - 87 e5 f9 2f fa 40 6a 63-8b a7 74 23 5e b3 ac 8f
.../.@jc..t#^...
0020 - 53 20 d3 f0 fe 3c 9d 68-57 3f 47 00 00 3a 00 39 S
...<.hW?G..:.9
0030 - 00 38 00 88 00 87 00 35-00 84 00 16 00 13 00 0a
.8.....5........
0040 - 00 33 00 32 00 9a 00 99-00 45 00 44 00 2f 00 96
.3.2.....E.D./..
0050 - 00 41 00 05 00 04 00 15-00 12 00 09 00 14 00 11
.A..............
0060 - 00 08 00 06 00 03 00 ff-02 01 00 00 04 00 23 ..............#
0071 -<SPACES/NULS>
read from 0x1d6e090 [0x1e12e20] (7 bytes => 0 (0x0))
140434478798664:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 113 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
What does the directory server access log show for the connection
attempt?
I can also post to fpast.org if that would be more convenient.
>>> s_client?
>>>> On Mon, Jan 09, 2012 at 16:41:36 -0600, Marc Sauton wrote:
>>>>> Review the 389 DS errors log file, and the config, it seem like TLS
did
>>>>> not start.
>>>>> Use the console UI a first time to review the working configuration,
>>>>> just for a test, and compare with the manual settings.
>>>>> M.
>>>>>
>>>>> On 01/09/2012 02:33 PM, Iain Morgan wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I'm attempting to configure 389 DS v1.2.9.14 on RHEL 6.2 to
use TLS with
>>>>>> a certificate issued by a CA. I was previously able to configure
TLS
>>>>>> support using a self-signed certificate on a test system using
389 DS
>>>>>> 1.2.8.2, but I am not having any success with the CA-issued
certificate.
>>>>>>
>>>>>> Using the GUI is not an option, but I have used certutil to
create the
>>>>>> key/certificate databases, generate a CSR, and subsequently
install the
>>>>>> CA certificate and the signed SSL certificate.
>>>>>>
>>>>>> The server has been configured to use the certificate and the
LDAPS
>>>>>> listener has been enabled. The server starts up without complaint
and
>>>>>> the error log shows that it is listening on both port 389 and
636.
>>>>>> However, attempts to connect to the LDAPS port fail:
>>>>>>
>>>>>> ds1.imorgan % openssl s_client -connect localhost:636
>>>>>> CONNECTED(00000003)
>>>>>> 140218505807688:error:140790E5:SSL routines:SSL23_WRITE:ssl
handshake
>>>>>> failure:s23_lib.c:184:
>>>>>> ---
>>>>>> no peer certificate available
>>>>>> ---
>>>>>> No client certificate CA names sent
>>>>>> ---
>>>>>> SSL handshake has read 0 bytes and written 113 bytes
>>>>>> ---
>>>>>> New, (NONE), Cipher is (NONE)
>>>>>> Secure Renegotiation IS NOT supported
>>>>>> Compression: NONE
>>>>>> Expansion: NONE
>>>>>> ---
>>>>>> ds1.imorgan %
>>>>>>
>>>>>> Unfortunately, there do not appear to be any log messages which
indicate
>>>>>> the source of the problem. I've played with the trust flags
for the
>>>>>> certificate and have even tried re-importing it; all to no
avail.
>>>>>>
>>>>>> Any help would be appreciated.
>>>>>>
>>>>>> Thanks
>>>>>>
6:23 p.m.
On Mon, Jan 09, 2012 at 17:47:56 -0600, Rich Megginson wrote:
On 01/09/2012 04:39 PM, Iain Morgan wrote:
> On Mon, Jan 09, 2012 at 17:18:30 -0600, Rich Megginson wrote:
>> On 01/09/2012 04:11 PM, Iain Morgan wrote:
>>> On Mon, Jan 09, 2012 at 16:59:33 -0600, Rich Megginson wrote:
>>>> On 01/09/2012 03:59 PM, Iain Morgan wrote:
>>>>> The error log does not report any issues. It indicates that ns-slapd
is
>>>>> listening on both port 389 and 636. and it does not indicate any
errors
>>>>> at connection time.
>>>>>
>>>>> ds1.root # tail errors
>>>>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - signaling
operation
>>>>> threads
>>>>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - waiting for 15
>>>>> threads to terminate
>>>>> [09/Jan/2012:13:57:28 -0800] - slapd shutting down - closing down
>>>>> internal subsystems and plugins
>>>>> [09/Jan/2012:13:57:28 -0800] - Waiting for 4 database threads to
stop
>>>>> [09/Jan/2012:13:57:28 -0800] - All database threads now stopped
>>>>> [09/Jan/2012:13:57:28 -0800] - slapd stopped.
>>>>> [09/Jan/2012:13:57:29 -0800] - 389-Directory/1.2.9.14 B2011.312.195
>>>>> starting up
>>>>> [09/Jan/2012:13:57:29 -0800] - slapd started. Listening on
Loopback
>>>>> port 389 for LDAP requests
>>>>> [09/Jan/2012:13:57:29 -0800] - Listening on Loopback port 636 for
LDAPS
>>>>> requests
>>>>> [09/Jan/2012:13:57:29 -0800] - Listening on
/var/run/slapd-ds1.socket
>>>>> for LDAPI requests
>>>>> ds1.root #
>>>>>
>>>>> I've already compared the dse.ldif from the problem system to
the
>>>>> dse.ldif from the working system which uses a self-signed
certificate.
>>>>> The only difference of note was the addition of the
>>>>> nsslapd-validate-cert attribute in the problem server.
Incidentally,
>>>>> changing the value of that attribute from "warn" to
"on" or "off" made
>>>>> no difference.
>>>>>
>>>>> And, as mentioned in the original post, using the console GUI is not
an
>>>>> option.
>>>> What happens if you specify the -CAfile filename arguments to openssl
>>> I get the same behaviour with -CAfile set.
>> ok - try this
>>
>> openssl s_client -showcerts -debug -connect localhost:636
>>
>> remove/obscure any sensitive information in the output, paste it to
>> fpaste.org, and post the link here
> Actually, the output is short enough that I might as well post it
> inline:
>
> ds1.imorgan % openssl s_client -showcerts -debug -connect localhost:636
> CONNECTED(00000003)
> write to 0x1d6e090 [0x1e0d8c0] (113 bytes => 113 (0x71))
> 0000 - 16 03 01 00 6c 01 00 00-68 03 01 4f 0b 78 fa 9c
> ....l...h..O.x..
> 0010 - 87 e5 f9 2f fa 40 6a 63-8b a7 74 23 5e b3 ac 8f
> .../.@jc..t#^...
> 0020 - 53 20 d3 f0 fe 3c 9d 68-57 3f 47 00 00 3a 00 39 S
> ...<.hW?G..:.9
> 0030 - 00 38 00 88 00 87 00 35-00 84 00 16 00 13 00 0a
> .8.....5........
> 0040 - 00 33 00 32 00 9a 00 99-00 45 00 44 00 2f 00 96
> .3.2.....E.D./..
> 0050 - 00 41 00 05 00 04 00 15-00 12 00 09 00 14 00 11
> .A..............
> 0060 - 00 08 00 06 00 03 00 ff-02 01 00 00 04 00 23 ..............#
> 0071 -<SPACES/NULS>
> read from 0x1d6e090 [0x1e12e20] (7 bytes => 0 (0x0))
> 140434478798664:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:s23_lib.c:184:
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 113 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
What does the directory server access log show for the connection attempt?
Doh! I had looked at this before, but had overlooked the critical
message:
[09/Jan/2012:15:08:19 -0800] conn=5 fd=64 slot=64 SSL connection from
127.0.0.1 to 127.0.0.1
[09/Jan/2012:15:08:19 -0800] conn=5 op=-1 fd=64 closed - No certificate
authority is trusted for SSL client authentication.
[09/Jan/2012:15:32:10 -0800] conn=6 fd=64 slot=64 SSL connection from
127.0.0.1 to 127.0.0.1
[09/Jan/2012:15:32:10 -0800] conn=6 op=-1 fd=64 closed - No certificate
authority is trusted for SSL client authentication.
ds1.root #
I had the trust flags on the CA file set to "C,," rather than "CT,,".
After changing the trust flags, it now works!
Thanks for your help.
--
Iain
> I can also post to fpast.org if that would be more convenient.
>>>> s_client?
>>>>> On Mon, Jan 09, 2012 at 16:41:36 -0600, Marc Sauton wrote:
>>>>>> Review the 389 DS errors log file, and the config, it seem like
TLS did
>>>>>> not start.
>>>>>> Use the console UI a first time to review the working
configuration,
>>>>>> just for a test, and compare with the manual settings.
>>>>>> M.
>>>>>>
>>>>>> On 01/09/2012 02:33 PM, Iain Morgan wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm attempting to configure 389 DS v1.2.9.14 on RHEL 6.2
to use TLS with
>>>>>>> a certificate issued by a CA. I was previously able to
configure TLS
>>>>>>> support using a self-signed certificate on a test system
using 389 DS
>>>>>>> 1.2.8.2, but I am not having any success with the CA-issued
certificate.
>>>>>>>
>>>>>>> Using the GUI is not an option, but I have used certutil to
create the
>>>>>>> key/certificate databases, generate a CSR, and subsequently
install the
>>>>>>> CA certificate and the signed SSL certificate.
>>>>>>>
>>>>>>> The server has been configured to use the certificate and
the LDAPS
>>>>>>> listener has been enabled. The server starts up without
complaint and
>>>>>>> the error log shows that it is listening on both port 389
and 636.
>>>>>>> However, attempts to connect to the LDAPS port fail:
>>>>>>>
>>>>>>> ds1.imorgan % openssl s_client -connect localhost:636
>>>>>>> CONNECTED(00000003)
>>>>>>> 140218505807688:error:140790E5:SSL routines:SSL23_WRITE:ssl
handshake
>>>>>>> failure:s23_lib.c:184:
>>>>>>> ---
>>>>>>> no peer certificate available
>>>>>>> ---
>>>>>>> No client certificate CA names sent
>>>>>>> ---
>>>>>>> SSL handshake has read 0 bytes and written 113 bytes
>>>>>>> ---
>>>>>>> New, (NONE), Cipher is (NONE)
>>>>>>> Secure Renegotiation IS NOT supported
>>>>>>> Compression: NONE
>>>>>>> Expansion: NONE
>>>>>>> ---
>>>>>>> ds1.imorgan %
>>>>>>>
>>>>>>> Unfortunately, there do not appear to be any log messages
which indicate
>>>>>>> the source of the problem. I've played with the trust
flags for the
>>>>>>> certificate and have even tried re-importing it; all to no
avail.
>>>>>>>
>>>>>>> Any help would be appreciated.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
--
Iain Morgan
4488
days inactive
4489
days old
389-users@lists.fedoraproject.org
8 comments
3 participants
participants (3)
-
Iain Morgan -
Marc Sauton -
Rich Megginson