RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1706224 - Protocol setting is inconsistent in FIPS mode
Summary: Protocol setting is inconsistent in FIPS mode
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: 389-ds-base
Version: ---
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: rc
: 8.1
Assignee: mreynolds
QA Contact: RHDS QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-03 20:24 UTC by Rob Crittenden
Modified: 2021-04-29 15:33 UTC (History)
10 users (show)

Fixed In Version: 389-ds-base-1.4.1.3-3.module+el8.1.0+3533+f8225121
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 21:00:29 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 3421 0 None closed Protocol setting is inconsistent in FIPS mode 2020-12-03 13:52:23 UTC
Red Hat Product Errata RHSA-2019:3401 0 None None None 2019-11-05 21:00:43 UTC

Description Rob Crittenden 2019-05-03 20:24:01 UTC 
Description of problem:

Installing IdM in FIPS mode fails near the end when the DM password is reset over startTLS with a TLS alert.

ldap_start_tls: Connect error (-11) additional info: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

If a min/max value is provided directly for the TLS configuration, even if it matches the default, the installation is successful and LDAP responds.

dn: cn=encryption,cn=config
sslVersionMin: TLS1.0
sslVersionMax: TLS1.3

The TLS configuration messages look identical between a non-working:

[03/May/2019:16:12:45.637681302 -0400] - INFO - Security Initialization - slapd_ssl_init2 - Configured SSL version range: min: TLS1.0, max: TLS1.3

and a working configuration.

[03/May/2019:16:14:45.367855588 -0400] - INFO - Security Initialization - slapd_ssl_init2 - Configured SSL version range: min: TLS1.0, max: TLS1.3

When failing this is logged whenever a TLS/startTLS connection is made:

[03/May/2019:16:14:48.486690472 -0400] conn=5 fd=66 slot=66 connection from 192.168.121.98 to 192.168.121.98
[03/May/2019:16:14:48.486995136 -0400] conn=5 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin"
[03/May/2019:16:14:48.487029802 -0400] conn=5 op=0 RESULT err=0 tag=120 nentries=0 etime=0.0000314375
[03/May/2019:16:14:48.487289319 -0400] conn=5 op=-1 fd=66 closed - security library failure.
[03/May/2019:16:14:48.674047457 -0400] conn=2 op=1 UNBIND
[03/May/2019:16:14:48.674067633 -0400] conn=2 op=1 fd=65 closed - U1

The client receives an error about a tls alert (duplicated using ldapsearch and ldappasswd).

Note that this was discovered while ensuring IdM works in FIPS mode. Other unrelated issues were detected as well.

Version-Release number of selected component (if applicable):
389-ds-base-1.4.0.20-10.module+el8.0.0+3096+101825d5.x86_64
Comment 1 mreynolds 2019-05-08 15:30:21 UTC 
More info...

So in this case the problem seems to occur when NSS converts the requested min version from (TLS1.0 to TLS1.2):

sslStatus = SSL_VersionRangeSet(pr_sock, &slapdNSSVersions);

But if we "get" the range after doing the initial "set", and then reset it again with the adjusted values then things start working:

sslStatus = SSL_VersionRangeSet(pr_sock, &slapdNSSVersions);
sslStatus = SSL_VersionRangeGet(pr_sock, &slapdNSSVersions);
sslStatus = SSL_VersionRangeSet(pr_sock, &slapdNSSVersions);

If it does convert the range then all TLS connections fail.  If it doesn't have to convert it then it works as expected.
Comment 2 Rob Crittenden 2019-05-08 15:39:24 UTC 
My open questions are:

- 389-ds is effectively trying to override the crypto policy which enables only TLS 1.2. Should this work as a general principal?
- Does being in FIPS mode have anything to do with this?

Note that I can duplicate similar behavior using selfserv:

# /usr/lib64/nss/unsupported-tools/selfserv -n Server-Cert -d . -Vtls1.0:tls1.2 -p 999 -f pwdfile.txt -v

When hit using TLS 1.1 it reports:

# openssl s_client -host `hostname` -port 999 -tls1_1

selfserv: About to call accept.
selfserv: HDX PR_Read returned error -12279:
Peer using unsupported version of security protocol.
Comment 4 mreynolds 2019-05-09 17:47:54 UTC 
Upstream ticket:
https://pagure.io/389-ds-base/issue/50362
Comment 5 mreynolds 2019-06-18 19:55:32 UTC 
This was actually fixed in:  https://pagure.io/389-ds-base/issue/50355
Comment 7 Viktor Ashirov 2019-08-22 09:47:40 UTC 
===================================================================== test session starts =====================================================================
platform linux -- Python 3.6.8, pytest-5.1.1, py-1.8.0, pluggy-0.12.0 -- /usr/bin/python3.6
cachedir: .pytest_cache
389-ds-base: 1.4.1.3-5.module+el8.1.0+3776+ece1ae4c
nss: 3.44.0-8.el8
nspr: 4.21.0-2.el8_0
openldap: 2.4.46-10.el8
cyrus-sasl: not installed
FIPS: enabled
rootdir: /root/389-ds-base/dirsrvtests, inifile: pytest.ini
collected 1 item                                                                                                                                              

dirsrvtests/tests/suites/tls/ssl_version_test.py::test_ssl_version_range PASSED                                                                         [100%]

===================================================================== 1 passed in 36.87s ======================================================================

Marking as VERIFIED.
Comment 9 errata-xmlrpc 2019-11-05 21:00:29 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3401
Note You need to log in before you can comment on or make changes to this bug.