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
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
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
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
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
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
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
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 >
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.
389-users@lists.fedoraproject.org
-
Iain Morgan -
Marc Sauton -
Rich Megginson