Bug 871171

Summary: Provide Tomcat support for TLS v1.1 and TLS v1.2 (Tomcatjss)
Product: Red Hat Enterprise Linux 7 Reporter: Christina Fu <cfu>
Component: tomcatjssAssignee: Christina Fu <cfu>
Status: CLOSED ERRATA QA Contact: Asha Akkiangady <aakkiang>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.0CC: cfu, jgalipea, mharmsen, nhosoi, nkinder, rpattath, rrelyea
Target Milestone: rcKeywords: FutureFeature
Target Release: 7.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tomcatjss-7.1.0-5.el7 pki-core-10.1.2-5.el7 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1167471 (view as bug list) Environment:
Last Closed: 2015-03-05 11:28:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 816396, 1167470    
Bug Blocks: 1167471    
Attachments:
Description Flags
tomcatjss support for TLS v. 1.1
none
/var/log/messages entries when start pki-tomcat service after modifying server.xml
none
script to set up ssl on DS.
none
ldif file for enabling ssl on ldap
none
pkispawn CA config file none

Description Christina Fu 2012-10-29 19:37:34 UTC 
this bug originated from https://bugzilla.redhat.com/show_bug.cgi?id=816396
Provide Tomcat support for TLS v1.1 via NSS through JSS . . .
where 816396 will contain fix for the JSS component, and this bug will contain the fix for Tomcatjss.
Comment 2 Christina Fu 2012-10-30 20:11:00 UTC 
Created attachment 635773 [details]
tomcatjss support for TLS v. 1.1

This is temporarily submitted and not to be reviewed until later when we are more ready.
Comment 4 Matthew Harmsen 2014-07-21 21:57:51 UTC 
NSS 3.15.1+ supports TLSv1.2, so tomcatjss should enable it now as well. Support
was added to NSS via BZ https://bugzilla.mozilla.org/show_bug.cgi?id=480514, and RHEL 7.1 will contain NSS 3.16.2.
Comment 6 Christina Fu 2014-10-01 17:37:03 UTC 
Fix/Testing information:

The fix provides the minimum code to support setting the ssl version range from tomcatjss server.
The tlsv1.1 and 1.2 ciphers are made available as well.

This fix works in conjunction with the fix for JSS bug (jss-4.2.6-35.el7):
Bug 816396 - Provide Tomcat support for TLS v1.1 and TLS v1.2 via NSS through JSS . . .

There are three new variables introduced in the server.xml:
(NOTE: server.xml has not been changed to add any info or default for the 
following values.  You will need to manually add them for testing)

sslVersionRangeStream - for stream protocol type.  it takes a format of "min:max" where min/max values can be "ssl3, tls1_0, tls1_1, or tls1_2"
sslVersionRangeDatagram - for datagram protocol type. it takes a format of "min:max" where min/max values can be "tls1_1, or tls1_2"
sslRangeCiphers - a complete list of ciphers you wish to support (provided supported by NSS) in such ssl version range.

Example:
sslVersionRangeStream="tls1_0:tls1_2"
sslVersionRangeDatagram="tls1_1:tls1_2"
      sslRangeCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,+TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_DSS_WITH_AES_128_CBC_SHA,+TLS_DHE_DSS_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_CBC_SHA256,+TLS_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256"

When the new *range* parameters are set, the old sslOptions parameter is ignored, as it is obsolete.  However, if the *range* parameters are not specified, the sslOptions will be supported, but see the following note from
rrelyea on how it differs from before inside NSS:

NSS detail re ssl range from rrelyea:
"
At the NSS level:

There is only range now. We added range before we added TLS 1.1. So the old code was SSL2 on/off SSL3 on/off, and TLS 1.0 on/off. Now we have TLS_range 0 = ssl3, 1=tls 1.0, 2=tls 1.1, 3=tls 1.2 (SSL2 is still on/off). The old functions that turned on ciphers still operate, but they work by extending the range. If TLS 1.1, and tls 1.2 are turned off, then it all works the same way it did before (the range is ssl3-tls.10). If tls 1.1 is on, though, now turning on ssl3 will also turn on tls 1.0 as a side effect. You can't turn on just ssl 3.0 and TLS 1.2, for example. If your old sslOptions have tls 1.1 or tls 1.2 as options, you wont' be able to turn them on in NSS without invoking a range.
"

Currently, I have not found a tool (client) that can test out the sha2 ciphers, so in testing, if you strip sslRangeCiphers down to those sha2 ciphers, you will find the Firefox browser not being able to connect.  In my opinion, that is good enough for testing purpose (it's undoubtly secure).
Comment 7 Roshni 2014-11-05 17:42:43 UTC 
Created attachment 954116 [details]
/var/log/messages entries when start pki-tomcat service after modifying server.xml
Comment 8 Roshni 2014-11-05 17:52:10 UTC 
Trying to verify the bug as follows:

Created a CA subsystem instance and stopped the tomcat service.

Modified the server.xml file as follows:

    <Connector name="Secure" port="30042" protocol="HTTP/1.1" SSLEnabled="true" sslProtocol="SSL" scheme="https" secure="true"
           maxHttpHeaderSize="8192"
           acceptCount="100" maxThreads="150" minSpareThreads="25"
           enableLookups="false" disableUploadTimeout="true"
           sslImplementationName="org.apache.tomcat.util.net.jss.JSSImplementation"
           enableOCSP="false"
           ocspResponderURL="http://nocp9.idm.lab.eng.rdu2.redhat.com:9080/ca/ocsp"
           ocspResponderCertNickname="ocspSigningCert cert-pki-ca"
           ocspCacheSize="1000"
           ocspMinCacheEntryDuration="60"
           ocspMaxCacheEntryDuration="120"
           ocspTimeout="10"
           strictCiphers="false"
           clientAuth="want"
           sslOptions="ssl2=true,ssl3=true,tls=true"
           ssl2Ciphers="-SSL2_RC4_128_WITH_MD5,-SSL2_RC4_128_EXPORT40_WITH_MD5,-SSL2_RC2_128_CBC_WITH_MD5,-SSL2_RC2_128_CBC_EXPORT40_WITH_MD5,-SSL2_DES_64_CBC_WITH_MD5,-SSL2_DES_192_EDE3_CBC_WITH_MD5"
           ssl3Ciphers="-SSL3_FORTEZZA_DMS_WITH_NULL_SHA,-SSL3_FORTEZZA_DMS_WITH_RC4_128_SHA,+SSL3_RSA_WITH_RC4_128_SHA,-SSL3_RSA_EXPORT_WITH_RC4_40_MD5,+SSL3_RSA_WITH_3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_DES_CBC_SHA,-SSL3_RSA_EXPORT_WITH_RC2_CBC_40_MD5,-SSL3_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA,-SSL_RSA_FIPS_WITH_DES_CBC_SHA,+SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_NULL_MD5,-TLS_RSA_EXPORT1024_WITH_RC4_56_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA"
           tlsCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,+TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_DSS_WITH_AES_128_CBC_SHA,+TLS_DHE_DSS_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA"
           serverCertNickFile="/var/lib/pki/pki-master/conf/serverCertNick.conf"
           passwordFile="/var/lib/pki/pki-master/conf/password.conf"
           passwordClass="org.apache.tomcat.util.net.jss.PlainPasswordFile"
           certdbDir="/var/lib/pki/pki-master/alias"
	   sslVersionRangeStream="tls1_0:tls1_2"
	   sslVersionRangeDatagram="tls1_1:tls1_2"
	   sslRangeCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,-TLS_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_RSA_WITH_AES_128_CBC_SHA,-TLS_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,-TLS_DHE_DSS_WITH_AES_128_CBC_SHA,-TLS_DHE_DSS_WITH_AES_256_CBC_SHA,-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_DHE_RSA_WITH_AES_128_CBC_SHA,-TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_CBC_SHA256,+TLS_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256"
           />

What I changed here is I added the params sslVersionRangeStream and sslVersionRangeDatagram just as explained by cfu. Disabled all sslRangeCiphers except the ones which use SHA256.

Starting back the pki-tomcat server gives error messages in the /var/log/messages (see attachment in comment 7). CA is restarted successfully and the secure EE page of CA is inaccessible. 

I also have one more question:

 
> sslVersionRangeStream - for stream protocol type.  it takes a format of
> "min:max" where min/max values can be "ssl3, tls1_0, tls1_1, or tls1_2"
> sslVersionRangeDatagram - for datagram protocol type. it takes a format of
> "min:max" where min/max values can be "tls1_1, or tls1_2"
> sslRangeCiphers - a complete list of ciphers you wish to support (provided
> supported by NSS) in such ssl version range.
> 
> Example:
> sslVersionRangeStream="tls1_0:tls1_2"
> sslVersionRangeDatagram="tls1_1:tls1_2"

Could either Bob or Christina explain the above parameters in terms of Bob explanation below (NSS detail). Basically what does sslVersionRangeStream="tls1_0:tls1_2 and sslVersionRangeDatagram="tls1_1:tls1_2 mean?

>      
> sslRangeCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-
> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,
> +TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
> +TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,
> +TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
> +TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> +TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
> +TLS_DHE_DSS_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
> +TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
> +TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
> +TLS_RSA_WITH_AES_128_CBC_SHA256,+TLS_RSA_WITH_AES_256_CBC_SHA256,
> +TLS_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
> +TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
> +TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
> +TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
> +TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
> +TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
> +TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256"
> 
> When the new *range* parameters are set, the old sslOptions parameter is
> ignored, as it is obsolete.  However, if the *range* parameters are not
> specified, the sslOptions will be supported, but see the following note from
> rrelyea on how it differs from before inside NSS:
> 
> NSS detail re ssl range from rrelyea:
> "
> At the NSS level:
> 
> There is only range now. We added range before we added TLS 1.1. So the old
> code was SSL2 on/off SSL3 on/off, and TLS 1.0 on/off. Now we have TLS_range
> 0 = ssl3, 1=tls 1.0, 2=tls 1.1, 3=tls 1.2 (SSL2 is still on/off). The old
> functions that turned on ciphers still operate, but they work by extending
> the range. If TLS 1.1, and tls 1.2 are turned off, then it all works the
> same way it did before (the range is ssl3-tls.10). If tls 1.1 is on, though,
> now turning on ssl3 will also turn on tls 1.0 as a side effect. You can't
> turn on just ssl 3.0 and TLS 1.2, for example. If your old sslOptions have
> tls 1.1 or tls 1.2 as options, you wont' be able to turn them on in NSS
> without invoking a range.
> "
> 
> Currently, I have not found a tool (client) that can test out the sha2
> ciphers, so in testing, if you strip sslRangeCiphers down to those sha2
> ciphers, you will find the Firefox browser not being able to connect.  In my
> opinion, that is good enough for testing purpose (it's undoubtly secure).
Comment 9 Christina Fu 2014-11-06 16:58:21 UTC 
this is my reply to Comment 8:

Roshni, you said
"What I changed here is I added the params sslVersionRangeStream and sslVersionRangeDatagram just as explained by cfu. Disabled all sslRangeCiphers except the ones which use SHA256."

I don't think I ever said to "disable all sslRangeCiphers except the ones which use SHA256" in the instruction.  SHA256 is only available for TLS1.2 and as I mentioned in comment 6, I have yet to find any tools that supports TLS1.2 (Firefox included).
You are welcome to hunt down a tool that supports TLS1.2 to test this bug, if you wish.

You asked about what the range indication means.  It's a range. so for example,
"tls1_0:tls1_2" means from tls1.0 to tls1.2 (that means tls1.0, tls1.1, and tls1.2)

Hope this helps,
Christina
Comment 10 Roshni 2014-11-07 19:39:27 UTC 
Christina,

Please have a look at the attachment in comment 7. I see some error messages in /var/log/messages when ssl Range related parameters are added to server.xml.
Comment 11 Christina Fu 2014-11-07 22:28:10 UTC 
Roshni, how about you attach your server.xml?
Comment 12 Roshni 2014-11-10 16:30:51 UTC 
Do not see the error in the log when tried on a fresh RHEL 7.1 machine machine using tomcatjss-7.1.0-5.el7.noarch. 

Added the following parameters to server.xml file to enable TLS v1.1 to TLS v1.2

sslVersionRangeStream="tls1_0:tls1_2"
sslVersionRangeDatagram="tls1_1:tls1_2"
      sslRangeCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,+TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_DSS_WITH_AES_128_CBC_SHA,+TLS_DHE_DSS_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_CBC_SHA256,+TLS_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256"

Tried to access the secure page after enabling only the SHA2 ciphers. Connection failed with the message that supported ciphers were not found.

I tried the same using just the list of TLS ciphers using SHA1. The connection succeeds if the supported cipher is enabled and fails if the supported cipher is disabled.
Comment 13 Christina Fu 2014-11-10 21:40:52 UTC 
This was discussed in CS meeting today.  It would be best if you put tls restriction in CS, you do similar setup with ldaps as well to test.
I do not have instruction at hand on the ldaps side, Noriko could you please provide info?
On the CS side, just find and follow into on turning on ssl for ldap.

It is expected that if you restrict both cs and ldap to TLS1.2, for example, they should still talk to each other.
I suggest you first set up ldaps just to be sure it is working before going through the process of doing tls restriction.
Comment 14 Christina Fu 2014-11-12 18:28:36 UTC 
The following came from Noriko:

This is not an official bit, but a scratch build.  But I verified it picks up up to TLS1.2 for the SSL version max.

Scratch build 389-ds-base-1.3.3.1-7.99.el7: https://brewweb.devel.redhat.com/taskinfo?taskID=8217228

Snippet of the Directory Server's access log:

    SSL
    .. conn=3 fd=64 slot=64 SSL connection from ::1 to ::1
    .. conn=3 TLS1.2 128-bit AES-GCM

    startTLS
    .. conn=4 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS"
    .. conn=4 op=0 RESULT err=0 tag=120 nentries=0 etime=0
    .. conn=4 TLS1.2 128-bit AES-GCM

Thanks,
--noriko

=====
Noriko, could you please also provide QE info on how to you did the configuration when you tested the ldap server? Thanks.

And Roshni, per comment #13, you are to test CS as a client to the DS server using the new TLS range setting and see if that has the desried effect.
Another thing is that you said you found openssl tool that can test this, could you provide info for future reference?  thanks.
Comment 15 Noriko Hosoi 2014-11-12 18:50:19 UTC 
Created attachment 956851 [details]
script to set up ssl on DS.

(In reply to Christina Fu from comment #14)
> The following came from Noriko:
> 
> This is not an official bit, but a scratch build.  But I verified it picks
> up up to TLS1.2 for the SSL version max.
> 
> Scratch build 389-ds-base-1.3.3.1-7.99.el7:
> https://brewweb.devel.redhat.com/taskinfo?taskID=8217228
> 
> Snippet of the Directory Server's access log:
> 
>     SSL
>     .. conn=3 fd=64 slot=64 SSL connection from ::1 to ::1
>     .. conn=3 TLS1.2 128-bit AES-GCM
> 
>     startTLS
>     .. conn=4 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS"
>     .. conn=4 op=0 RESULT err=0 tag=120 nentries=0 etime=0
>     .. conn=4 TLS1.2 128-bit AES-GCM
> 
> Thanks,
> --noriko
> 
> =====
> Noriko, could you please also provide QE info on how to you did the
> configuration when you tested the ldap server? Thanks.
> 
> And Roshni, per comment #13, you are to test CS as a client to the DS server
> using the new TLS range setting and see if that has the desried effect.
> Another thing is that you said you found openssl tool that can test this,
> could you provide info for future reference?  thanks.

1. Install Directory server with Admin Server (setup-ds-admin.pl)
2. Run setupssl2.sh as follows
# /path/to/setupssl2.sh /etc/dirsrv/slapd-YOURID PORT SSLPORT DIRECTORY_MANAGER_PASSWORD
3. Restart the DS and Admin Server
4. run ldapsearch over SSL and startTLS
5. check the access log /var/log/dirsrv/slapd-YOURID/access and see if the expected SSL version is found or not.
Comment 16 Roshni 2014-11-14 15:07:04 UTC 
I tried the following:

1. setup-ds.pl - instance-name=pki-ca-ldap, baseDN=dc=pki-ca

2. pkispawn CA

3. Run setupssl2.sh as follows
# /path/to/setupssl2.sh /etc/dirsrv/slapd-pki-ca-ldap 389 636 DIRECTORY_MANAGER_PASSWORD

4. Restart the DS

5. cd /etc/dirsrv/slapd-pki-ca-ldap

6. /usr/lib64/mozldap/ldapsearch -Z -h blade03.idm.lab.eng.rdu2.redhat.com -p 636 -D "cn=Directory Manager" -w Secret123 -b "dc=pki-ca" "objectclass=*"
ldapsearch was successfull and the access log had the chosen cipher

7. Removed the certs under ldap directory and added a ldap server cert generated by the CA created in step 2 and the CA's signing cert

8. Stop CA server

9. Modified CA's CS.cfg as follows:
   internaldb.ldapconn.port=636
   internaldb.ldapconn.secureConn=true

10. Modified server.xml with:
    
    sslVersionRangeStream="tls1_0:tls1_2"
sslVersionRangeDatagram="tls1_1:tls1_2"
      sslRangeCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,+TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_DSS_WITH_AES_128_CBC_SHA,+TLS_DHE_DSS_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_CBC_SHA256,+TLS_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256"

11. Start CA Server

Seeing the following in debug log:

[13/Nov/2014:15:28:17][localhost-startStop-1]: CMS:Caught EBaseException
Internal Database Error encountered: Could not connect to LDAP server host localhost port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
	at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:658)
	at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:934)
	at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:865)
	at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:362)
	at com.netscape.certsrv.apps.CMS.init(CMS.java:189)
	at com.netscape.certsrv.apps.CMS.start(CMS.java:1585)
	at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114)
	at javax.servlet.GenericServlet.init(GenericServlet.java:158)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
	at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672)
	at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)
[13/Nov/2014:15:28:17][localhost-startStop-1]: CMSEngine.shutdown()


Seeing the following in DS access log:

[13/Nov/2014:15:28:16 -0500] conn=5 fd=64 slot=64 SSL connection from 127.0.0.1 to 127.0.0.1
[13/Nov/2014:15:28:16 -0500] conn=5 op=-1 fd=64 closed - SSL peer cannot verify your certificate.
Comment 17 Christina Fu 2014-11-14 18:27:44 UTC 
This is in response to Comment #16.
Roshni, thanks for testing it out. I was able to reproduce.  I will investigate.
Comment 18 Roshni 2014-11-14 20:25:04 UTC 
Created attachment 957715 [details]
ldif file for enabling ssl on ldap
Comment 19 Roshni 2014-11-14 20:29:22 UTC 
Using the ldif file (attached in comment 18), no changes made to server.xml, same changes made to CS.cfg as explained in comment16. 

/var/log/pki/pki-master/ca/debug has

[14/Nov/2014:15:21:14][localhost-startStop-1]: CMS:Caught EBaseException
Internal Database Error encountered: Could not connect to LDAP server host localhost port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
	at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:658)
	at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:934)
	at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:865)
	at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:362)
	at com.netscape.certsrv.apps.CMS.init(CMS.java:189)
	at com.netscape.certsrv.apps.CMS.start(CMS.java:1585)
	at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114)
	at javax.servlet.GenericServlet.init(GenericServlet.java:158)
	at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
	at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
	at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
	at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
	at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
	at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672)
	at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)


/var/log/dirsrv/slapd-pki-ca-ldap/access has

[14/Nov/2014:15:21:14 -0500] conn=2 fd=64 slot=64 SSL connection from 127.0.0.1 to 127.0.0.1
[14/Nov/2014:15:21:14 -0500] conn=2 op=-1 fd=64 closed - Cannot communicate securely with peer: no common encryption algorithm(s).
Comment 20 Christina Fu 2014-11-15 00:09:58 UTC 
I actually expanded (with Noriko's help) the ssl version range to include ssl3 on the ds side and now ca and ds connects via secure port.
That means the cs server when acting as ldap client did not set the range correctly as I'd expect it to.

1.
This should probably be considered a separate bug from this one, as the tomcat server works correctly as a server. So, you can close this bug.

2.
Roshni, could you please file a separate bug for cs when it is acting as an ldap client the tls range is not set?  thanks.
Comment 21 Roshni 2014-11-17 14:17:31 UTC 
Christina,

Could you provide me with the details on how you got the ds with ssl3 communicating with CA working? I want to try from my side.
Comment 22 Christina Fu 2014-11-17 17:39:37 UTC 
(In reply to Roshni from comment #21)
> Christina,
> 
> Could you provide me with the details on how you got the ds with ssl3
> communicating with CA working? I want to try from my side.

sure Roshni.  I'm not that familiar with DS, so what I did was probably not the most straight-forward way, but it got me there.
Basically, I first followed Noriko's steps in comment #15, minus installing the admin server, as there is no need for CS. And then I expand the range to include ssl3. Here are my steps:

* Install DS.  I used:
389-ds-base-1.3.3.1-9.el7.x86_64
389-ds-base-libs-1.3.3.1-9.el7.x86_64
* Install mozldap.  I used:
mozldap-6.0.5-7.1.el7dsrv.x86_64
* setup the ssl range:
  - run setupssl2.sh... e.g.
/root/cfu/setupssl2.sh /etc/dirsrv/slapd-pki-rhel7 389 636 < ds passwd>  
* restart ds
 systemctl restart dirsrv.target
* test to see if it works... e.g.:
/usr/lib64/mozldap/ldapsearch -Z -h <host> -p 636 -b "dc=usersys, dc=redhat, dc=com" -D "cn=Directory Manager" -w <ds passwd> "objectclass=*"
* stop ds
 systemctl stop dirsrv.target
* modify ldif
  - under cn=encryption,cn=config
     add or replace (depending on what you have), set the following
    nsSSL3: on
    nsTLS1: on
    sslVersionMin: SSL3
(I think the setupssl2.sh already set the max, so you are good with max)
* restart ds
 systemctl restart dirsrv.target

Now setup CS instance, and set up the trust.  I actually just used the ds's temp ca:
* cd /etc/dirsrv/slapd-instance
* certutil -L -d . -n "CA certificate" -a > tempcacert.crt
* cd <ca instance>/alias
  certutil -A -i /etc/dirsrv/<ds instance>/tempcacert.crt -t "CT,C,C" -n "Temporary CA certificate" -a -d .
* check ca's server.xml and make sure you include ssl3
* restart ca
Comment 23 Christina Fu 2014-11-17 23:22:55 UTC 
FYI,  I just tested CA->KRA by restricting KRA down to TLS1_2 and CA appears to be working with KRA without issues.
The cipher that was picked in my test was determined to be:
 cipher_suite = (0xc02f) TLS/ECDHE-RSA/AES128-GCM/SHA256

Conclusion: the TLS client issue is limited to only when talking to the ldap server.
Comment 26 Christina Fu 2014-11-20 19:27:33 UTC 
Additional testing info:

In addition to testing CA->DS, a couple other areas are affected by this fix, so the tests need to cover them:

you want to test a higher tls range, so for example, change
sslVersionRangeStream="tls1_0:tls1_2"
to
sslVersionRangeStream="tls1_2:tls1_2"
restart your server
=====
* CLI -> CA
run cli to test like this (I'm leaving out the steps to setup, assuming you have them):
cd /<your home dir>/.dogtag/nssdb
pki -h <cs host> -p <ca https port> -P https cert-find

If you want, you can even check by running ssltap against the ca to be sure:
ssltap -sxl <cs host>:<ca https port>
and then run pki via ssl pointing at the ssltap port (default 1924):
pki -h <cs host> -p 1924 -P https cert-find

=====
* HttpClient -> CA
I assume you have instruction on how to do this.  Make sure the port in your HttpClient.cfg points to the secure port

=====
Just for the record, the test I mentioned in comment #23 for CA->KRA does not pertain to this platform, but will for 7.2.
Comment 28 Christina Fu 2014-11-20 19:43:09 UTC 
A couple more things:
* the java console was also not touched(fixed) at this time, as I was told it does not concern rhel 7.1.
* tools such as pki cli's and HttpClient are hard-coded to support tls1_0-tls1_2.  There is no plan to make them configurable at the moment.
Comment 29 Christina Fu 2014-11-26 02:00:21 UTC 
just for the record: fix committed to DOGTAG_10_2_RHEL_BRANCH

commit 249c04e06f4cd7226374791760f11b906543d2a3
Author: Christina Fu <cfu>
Date:   Tue Nov 18 18:28:53 2014 -0800

    bugzilla 871171 (client-side code) Provide Tomcat support for TLS v1.1 and T
...
To ssh://git.app.eng.bos.redhat.com/srv/git/pki.git
   8c6480b..249c04e  DOGTAG_10_2_RHEL_BRANCH -> DOGTAG_10_2_RHEL_BRANCH
Comment 30 Roshni 2014-11-26 02:16:19 UTC 
Created attachment 961442 [details]
pkispawn CA config file
Comment 31 Roshni 2014-11-26 02:18:11 UTC 
pkispawn CA fails using the attached (comment 30) config file

[root@qe-blade-03 ~]# systemctl status pki-tomcatd -l
pki-tomcatd - PKI Tomcat Server pki-master
   Loaded: loaded (/usr/lib/systemd/system/pki-tomcatd@.service; enabled)
   Active: failed (Result: exit-code) since Tue 2014-11-25 18:13:36 EST; 11min ago
  Process: 13412 ExecStartPre=/usr/bin/pkidaemon start tomcat %i (code=exited, status=1/FAILURE)

Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com pkidaemon[13412]: WARNING:  Attempting to change symbolic link '/var/lib/pki/pki-master/common/lib/jss4.jar' to point to target '/jss4.jar' INSTEAD of current target '/usr/lib/java/jss4.jar'!
Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com pkidaemon[13412]: INFO:  Removed '/var/lib/pki/pki-master/common/lib/jss4.jar' -> '/usr/lib/java/jss4.jar'!
Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com pkidaemon[13412]: INFO:  Attempting to create '/var/lib/pki/pki-master/common/lib/jss4.jar' -> '/jss4.jar' . . .
Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com pkidaemon[13412]: ERROR:  Failed making '/var/lib/pki/pki-master/common/lib/jss4.jar' -> '/jss4.jar' since target '/jss4.jar' does NOT exist!
Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com systemd[1]: pki-tomcatd: control process exited, code=exited status=1
Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com systemd[1]: Failed to start PKI Tomcat Server pki-master.
Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com systemd[1]: Unit pki-tomcatd entered failed state.


using the following builds

[root@qe-blade-03 ~]#  rpm -qa pki\*
pki-tools-10.1.2-6.el7.x86_64
pki-tks-10.1.2-6.el7.noarch
pki-base-10.1.2-6.el7.noarch
pki-ca-10.1.2-6.el7.noarch
pki-symkey-10.1.2-6.el7.x86_64
pki-kra-10.1.2-6.el7.noarch
pki-server-10.1.2-6.el7.noarch
pki-ocsp-10.1.2-6.el7.noarch
pki-javadoc-10.1.2-6.el7.noarch
pki-tps-tomcat-10.1.2-6.el7.noarch

[root@qe-blade-03 ~]# rpm -q tomcatjss
tomcatjss-7.1.0-5.el7.noarch

[root@qe-blade-03 ~]# rpm -q jss
jss-4.2.6-35.el7.x86_64
Comment 32 Matthew Harmsen 2014-11-26 07:17:04 UTC 
(In reply to Roshni from comment #31)
> pkispawn CA fails using the attached (comment 30) config file
> 
> [root@qe-blade-03 ~]# systemctl status pki-tomcatd -l
> pki-tomcatd - PKI Tomcat Server pki-master
>    Loaded: loaded (/usr/lib/systemd/system/pki-tomcatd@.service; enabled)
>    Active: failed (Result: exit-code) since Tue 2014-11-25 18:13:36 EST;
> 11min ago
>   Process: 13412 ExecStartPre=/usr/bin/pkidaemon start tomcat %i
> (code=exited, status=1/FAILURE)
> 
> Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com pkidaemon[13412]:
> WARNING:  Attempting to change symbolic link
> '/var/lib/pki/pki-master/common/lib/jss4.jar' to point to target '/jss4.jar'
> INSTEAD of current target '/usr/lib/java/jss4.jar'!
> Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com pkidaemon[13412]:
> INFO:  Removed '/var/lib/pki/pki-master/common/lib/jss4.jar' ->
> '/usr/lib/java/jss4.jar'!
> Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com pkidaemon[13412]:
> INFO:  Attempting to create '/var/lib/pki/pki-master/common/lib/jss4.jar' ->
> '/jss4.jar' . . .
> Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com pkidaemon[13412]:
> ERROR:  Failed making '/var/lib/pki/pki-master/common/lib/jss4.jar' ->
> '/jss4.jar' since target '/jss4.jar' does NOT exist!
> Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com systemd[1]:
> pki-tomcatd: control process exited, code=exited status=1
> Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com systemd[1]: Failed
> to start PKI Tomcat Server pki-master.
> Nov 25 18:13:36 qe-blade-03.idmqe.lab.eng.bos.redhat.com systemd[1]: Unit
> pki-tomcatd entered failed state.
> 
> 
> using the following builds
> 
> [root@qe-blade-03 ~]#  rpm -qa pki\*
> pki-tools-10.1.2-6.el7.x86_64
> pki-tks-10.1.2-6.el7.noarch
> pki-base-10.1.2-6.el7.noarch
> pki-ca-10.1.2-6.el7.noarch
> pki-symkey-10.1.2-6.el7.x86_64
> pki-kra-10.1.2-6.el7.noarch
> pki-server-10.1.2-6.el7.noarch
> pki-ocsp-10.1.2-6.el7.noarch
> pki-javadoc-10.1.2-6.el7.noarch
> pki-tps-tomcat-10.1.2-6.el7.noarch
> 
> [root@qe-blade-03 ~]# rpm -q tomcatjss
> tomcatjss-7.1.0-5.el7.noarch
> 
> [root@qe-blade-03 ~]# rpm -q jss
> jss-4.2.6-35.el7.x86_64

This appears to be caused by the recent change to 'Bugzilla Bug #1165351 - Errata TPS test fails due to dependent packages not found' in which the following code snippet apparently does not work when invoked via the 'systemctl' process:

    # Dogtag 10 Conditional Variables
    jni_jar_dir=`source /usr/share/pki/etc/pki.conf && echo $JNI_JAR_DIR`
    # Override jni_jar_dir using a user-defined value if one exists
    jni_jar_dir=`source /etc/pki/pki.conf && echo $JNI_JAR_DIR`

While this code was tested and found to work from shell scripts, the code within the '/usr/share/pki/scripts/operations' as called from the systemctl process will be changed to the following:

    # Use a user-defined value for jni_jar_dir if one exists
    jni_jar_dir=`source /etc/pki/pki.conf && echo $JNI_JAR_DIR`
    if [ -z ${jni_jar_dir} ] ; then
        # Otherwise set it to the default value
        jni_jar_dir=`source /usr/share/pki/etc/pki.conf && echo $JNI_JAR_DIR`
    fi

I will attempt to respin this package tomorrow -- please set 'Bugzilla Bug #1165351 - Errata TPS test fails due to dependent packages not found' back to NEW/ASSIGNED.
Comment 33 Roshni 2014-11-29 18:00:30 UTC 
After updating to the builds in https://errata.devel.redhat.com/advisory/18533 I tried with the steps in comment 16 and also tried the steps in comment 22. If CS.cfg has the following 

internaldb.ldapconn.port=636
internaldb.ldapconn.secureConn=true

I still the error message in the debug log on CA service restart

[29/Nov/2014:22:28:02][localhost-startStop-1]: init: before makeConnection errorIfDown is true
[29/Nov/2014:22:28:02][localhost-startStop-1]: makeConnection: errorIfDown true
[29/Nov/2014:22:28:02][localhost-startStop-1]: CMS:Caught EBaseException
Internal Database Error encountered: Could not connect to LDAP server host localhost port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
        at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:658)
        at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:934)
        at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:865)
        at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:362)
        at com.netscape.certsrv.apps.CMS.init(CMS.java:189)
        at com.netscape.certsrv.apps.CMS.start(CMS.java:1585)
        at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:96)
        at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
        at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
        at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
        at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
        at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672)
        at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)


Christina, does including SSL3 in server.xml mean the following

sslVersionRangeStream="tls0_0:tls1_2"
sslVersionRangeDatagram="tls1_1:tls1_2"

Could you also explain the terms RangeStream and RangeDatagram
Comment 34 Christina Fu 2014-12-01 17:05:02 UTC 
this is a reply to comment #33.
Roshni, please show me your entry content for
dn: cn=encryption,cn=config
in the ldif file.

I already explained the range in comment #6.  Let me know what is still not clear.

btw, I do not see this bug being mentioned in https://errata.devel.redhat.com/advisory/18533 (where you said you got the builds).  You want to check with Matt whether you are at the right place.

Hope this helps.
Comment 35 Roshni 2014-12-01 17:35:33 UTC 
(In reply to Christina Fu from comment #34)
> this is a reply to comment #33.
> Roshni, please show me your entry content for
> dn: cn=encryption,cn=config
> in the ldif file.

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL3: on
nsTLS1: on
sslVersionMin: SSL3
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=directory manager
createTimestamp: 20141129164414Z
modifyTimestamp: 20141129164515Z
sslVersionMax: TLS1.3
nsSSL3Ciphers: +all
numSubordinates: 1

> 
> I already explained the range in comment #6.  Let me know what is still not
> clear.

I want to know if including SSL3 in server.xml will look as follows

sslVersionRangeStream="tls0_0:tls1_2"

> 
> btw, I do not see this bug being mentioned in
> https://errata.devel.redhat.com/advisory/18533 (where you said you got the
> builds).  You want to check with Matt whether you are at the right place.

I was not able to perform pkispawn before the latest respin of the above errata. When I last tested I used

pki-core-10.1.2-7.el7
tomcatjss-7.1.0-5.el7.noarch
jss-4.2.6-35.el7.x86_64

I also noticed that in the steps explained in comment 22, I do not see making modifications to the CS.cfg to include the following

internaldb.ldapconn.port=636
internaldb.ldapconn.secureConn=true

Is that not required?
Comment 36 Christina Fu 2014-12-01 18:00:19 UTC 
this is a reply to comment #35,
1. The ldap entry looks fine, as far as I can tell.
2. As far as tomcatjss is concerned,
   min/max values can be "ssl3, tls1_0, tls1_1, or tls1_2"
When acting as ssl clients (e.g. when talking to DS server, or among themselves), cs servers will inherit the setting from tomcatjss.
3. yes, ldapconn needs to be updated.  My instruction only attempted to provide the new setps.  But it is a good idea to have a complete instruction for documentation purpose.
4. I just checked with Matt, I think your builds should contain the fix.
Comment 37 Roshni 2014-12-02 15:04:45 UTC 
Christina, I am changing the bug status to ON_QA because there are no new builds.

The following is the detailed description of the steps I followed to test CA with DS secure communication:

1. setup-ds.pl - instance-name=pki-ca-ldap, baseDN=dc=pki-ca

2. Run setupssl2.sh as follows
# /path/to/setupssl2.sh /etc/dirsrv/slapd-pki-ca-ldap 389 636 DIRECTORY_MANAGER_PASSWORD

3. stop DS

4. Modify dse.ldif as follows

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
sslVersionMin: TLS1.1
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=directory manager
createTimestamp: 20141201172101Z
modifyTimestamp: 20141201172356Z
sslVersionMax: TLS1.3
nsSSL3Ciphers: +all
numSubordinates: 1

5. start the DS

6. cd /etc/dirsrv/slapd-pki-ca-ldap

7. /usr/lib64/mozldap/ldapsearch -Z -h localhost -p 636 -D "cn=Directory Manager" -w Secret123 -b "dc=pki-ca" "objectclass=*" is successful

8. pkispawn CA

9. Stop CA

10. Modified CA's CS.cfg as follows:
   internaldb.ldapconn.port=636
   internaldb.ldapconn.secureConn=true

11. Modified server.xml with:
    
    sslVersionRangeStream="ssl3:tls1_2"

12. certutil -L -d /etc/dirsrv/slapd-pki-ca-ldap -n "CA certificate" -a > /var/lib/pki/pki-master/ca/alias/cacert.pem

certutil -A -d /var/lib/pki/pki-master/ca/alias/ -n "Temp CA Cert" -t "CT,CT,CT" -i /var/lib/pki/pki-master/ca/alias/cacert.pem


13. Start CA Server

Seeing the following in the debug log

[02/Dec/2014:20:26:33][localhost-startStop-1]: CMS:Caught EBaseException
Internal Database Error encountered: Could not connect to LDAP server host localhost port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1)
        at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:658)
        at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:934)
        at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:865)
        at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:362)
        at com.netscape.certsrv.apps.CMS.init(CMS.java:189)
        at com.netscape.certsrv.apps.CMS.start(CMS.java:1585)
        at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:96)
        at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284)
        at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197)
        at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
        at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
        at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672)
        at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)
[02/Dec/2014:20:26:33][localhost-startStop-1]: CMSEngine.shutdown()
Comment 38 Roshni 2014-12-02 17:40:14 UTC 
(In reply to Roshni from comment #37)
> Christina, I am changing the bug status to ON_QA because there are no new
> builds.
> 
> The following is the detailed description of the steps I followed to test CA
> with DS secure communication:
> 
> 1. setup-ds.pl - instance-name=pki-ca-ldap, baseDN=dc=pki-ca
> 
> 2. Run setupssl2.sh as follows
> # /path/to/setupssl2.sh /etc/dirsrv/slapd-pki-ca-ldap 389 636
> DIRECTORY_MANAGER_PASSWORD
> 
> 3. stop DS
> 
> 4. Modify dse.ldif as follows
> 
> dn: cn=encryption,cn=config
> objectClass: top
> objectClass: nsEncryptionConfig
> cn: encryption
> nsSSLSessionTimeout: 0
> nsSSLClientAuth: allowed
> sslVersionMin: TLS1.1
> creatorsName: cn=server,cn=plugins,cn=config
> modifiersName: cn=directory manager
> createTimestamp: 20141201172101Z
> modifyTimestamp: 20141201172356Z
> sslVersionMax: TLS1.3
> nsSSL3Ciphers: +all
> numSubordinates: 1

The above config was mis-typed, the following is the one I used

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL3: on
nsTLS1: on
sslVersionMin: SSL3
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=directory manager
createTimestamp: 20141202144236Z
modifyTimestamp: 20141202144338Z
sslVersionMax: TLS1.3
nsSSL3Ciphers: +all
numSubordinates: 1

> 
> 5. start the DS
> 
> 6. cd /etc/dirsrv/slapd-pki-ca-ldap
> 
> 7. /usr/lib64/mozldap/ldapsearch -Z -h localhost -p 636 -D "cn=Directory
> Manager" -w Secret123 -b "dc=pki-ca" "objectclass=*" is successful
> 
> 8. pkispawn CA
> 
> 9. Stop CA
> 
> 10. Modified CA's CS.cfg as follows:
>    internaldb.ldapconn.port=636
>    internaldb.ldapconn.secureConn=true
> 
> 11. Modified server.xml with:
>     
>     sslVersionRangeStream="ssl3:tls1_2"
> 
> 12. certutil -L -d /etc/dirsrv/slapd-pki-ca-ldap -n "CA certificate" -a >
> /var/lib/pki/pki-master/ca/alias/cacert.pem
> 
> certutil -A -d /var/lib/pki/pki-master/ca/alias/ -n "Temp CA Cert" -t
> "CT,CT,CT" -i /var/lib/pki/pki-master/ca/alias/cacert.pem
> 
> 
> 13. Start CA Server
> 
> Seeing the following in the debug log
> 
> [02/Dec/2014:20:26:33][localhost-startStop-1]: CMS:Caught EBaseException
> Internal Database Error encountered: Could not connect to LDAP server host
> localhost port 636 Error netscape.ldap.LDAPException: IO Error creating JSS
> SSL Socket (-1)
>         at com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:658)
>         at
> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:934)
>         at
> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:865)
>         at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:362)
>         at com.netscape.certsrv.apps.CMS.init(CMS.java:189)
>         at com.netscape.certsrv.apps.CMS.start(CMS.java:1585)
>         at
> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:96)
>         at
> org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:
> 1284)
>         at
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:
> 1197)
>         at
> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087)
>         at
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:
> 5210)
>         at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:
> 5493)
>         at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>         at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:
> 901)
>         at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
>         at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
>         at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672)
>         at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:
> 1862)
>         at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>         at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
> 1145)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:
> 615)
>         at java.lang.Thread.run(Thread.java:745)
> [02/Dec/2014:20:26:33][localhost-startStop-1]: CMSEngine.shutdown()
Comment 39 Christina Fu 2014-12-03 20:40:28 UTC 
Roshni, I think from our last irc exchange, you were going to try out the pkispawn config file I shared with you?  I'm clearing the needInfo here to reflect that.
Comment 40 Christina Fu 2014-12-03 20:47:36 UTC 
(In reply to Christina Fu from comment #39)
> Roshni, I think from our last irc exchange, you were going to try out the
> pkispawn config file I shared with you?  I'm clearing the needInfo here to
> reflect that.

Also, for the record, during our irc exchange, you provided me with the following ldap log per my request:
    [02/Dec/2014:20:26:33 +051800] conn=40 fd=64 slot=64 SSL connection from 127.0.0.1 to 127.0.0.1
    [02/Dec/2014:20:26:33 +051800] conn=40 op=-1 fd=64 closed - SSL peer cannot verify your certificate.
    [02/Dec/2014:20:27:20 +051800] conn=41 fd=64 slot=64 SSL connection from ::1 to ::1
    [02/Dec/2014:20:27:20 +051800] conn=41 TLS1.2 128-bit AES-GCM
    [02/Dec/2014:20:27:20 +051800] conn=41 op=0 BIND dn="cn=Directory Manager" method=128 version=3
    [02/Dec/2014:20:27:20 +051800] conn=41 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
    [02/Dec/2014:20:27:20 +051800] conn=41 op=1 SRCH base="dc=pki-ca" scope=2 filter="(objectClass=*)" attrs=ALL
    [02/Dec/2014:20:27:20 +051800] conn=41 op=1 RESULT err=0 tag=101 nentries=53 etime=0 notes=U
    [02/Dec/2014:20:27:20 +051800] conn=41 op=2 UNBIND
    [02/Dec/2014:20:27:20 +051800] conn=41 op=2 fd=64 closed - U1
    [02/Dec/2014:23:15:48 +051800] conn=42 fd=64 slot=64 SSL connection from 127.0.0.1 to 127.0.0.1
    [02/Dec/2014:23:15:48 +051800] conn=42 op=-1 fd=64 closed - SSL peer cannot verify your certificate.


Hopefully you will be able to resolve the "SSL peer cannot verify your certificate." issue.  That seems to be a configuration issue.
Comment 41 Roshni 2014-12-05 14:56:50 UTC 
The following are the verification steps:

CA -> DS

1. setup-ds.pl - instance-name=pki-ca-ldap, baseDN=dc=pki-ca

2. Run setupssl2.sh as follows
# /path/to/setupssl2.sh /etc/dirsrv/slapd-pki-ca-ldap 389 636 DIRECTORY_MANAGER_PASSWORD

3. cd /etc/dirsrv/slapd-pki-ca-ldap

4. /usr/lib64/mozldap/ldapsearch -Z -h localhost -p 636 -D "cn=Directory Manager" -w Secret123 -b "dc=pki-ca" "objectclass=*" is successful

5. pkispawn CA

6. Stop CA

. Modified CA's CS.cfg as follows:
   internaldb.ldapconn.host=blade01.idm.lab.eng.rdu2.redhat.com (make sure this param is not localhost)
   internaldb.ldapconn.port=636
   internaldb.ldapconn.secureConn=true

7. certutil -L -d /etc/dirsrv/slapd-pki-ca-ldap -n "CA certificate" -a > /var/lib/pki/pki-master/ca/alias/cacert.pem

certutil -A -d /var/lib/pki/pki-master/ca/alias/ -n "Temp CA Cert" -t "CT,CT,CT" -i /var/lib/pki/pki-master/ca/alias/cacert.pem

8. server.xml should have

sslVersionRangeStream="tls1_0:tls1_2"
sslVersionRangeDatagram="tls1_1:tls1_2"
           sslRangeCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,+TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_DSS_WITH_AES_128_CBC_SHA,+TLS_DHE_DSS_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_CBC_SHA256,+TLS_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256"


9. Start CA Server

The cipher used will be seen in the dirsrv instance access log

[05/Dec/2014:09:49:36 -0500] conn=48 fd=72 slot=72 SSL connection from 10.8.60.44 to 10.8.60.44
[05/Dec/2014:09:49:36 -0500] conn=48 TLS1.2 128-bit AES-GCM
[05/Dec/2014:09:49:36 -0500] conn=48 op=0 BIND dn="cn=Directory Manager" method=128 version=3
[05/Dec/2014:09:49:36 -0500] conn=48 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager"
[05/Dec/2014:09:49:36 -0500] conn=48 op=1 SRCH base="ou=sessions,ou=Security Domain,o=pki-ca-bug-CA" scope=2 filter="(objectClass=securityDomainSessionEntry)" attrs="cn"
[05/Dec/2014:09:49:36 -0500] conn=48 op=1 RESULT err=32 tag=101 nentries=0 etime=0
[05/Dec/2014:09:49:36 -0500] conn=40 op=10 SRCH base="ou=ca,ou=requests,o=pki-ca-bug-CA" scope=1 filter="(&(requestState=approved)(requestId=*))" attrs=ALL
[05/Dec/2014:09:49:36 -0500] conn=40 op=10 RESULT err=0 tag=101 nentries=0 etime=0 notes=U
[05/Dec/2014:09:54:37 -0500] conn=48 op=2 SRCH base="ou=sessions,ou=Security Domain,o=pki-ca-bug-CA" scope=2 filter="(objectClass=securityDomainSessionEntry)" attrs="cn"
[05/Dec/2014:09:54:37 -0500] conn=48 op=2 RESULT err=32 tag=101 nentries=0 etime=0


Also tested the additional tests in comment 26 and were successful.

HttpClient required an additional step of trusting the CA's signing cert under the security database
Comment 43 errata-xmlrpc 2015-03-05 11:28:04 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://rhn.redhat.com/errata/RHBA-2015-0522.html