A Java crawler developed on Apache HttpClient works fine on Windows, but throws "Algorithm constraints check failed on signature algorithm: SHA1withRSA" on Linux when crawling sites having certificate signed by Certum. Both ran on the latest openjdk-11. java.security on both OSes are compared and properties like jdk.certpath.disabledAlgorithms and jdk.security.legacyAlgorithms are the same. I even tried to comment all these properties on the Linux, no no success. Linux ca-certs are up to date and Certum is also trusted on java keystore there. Tools like curl and wget can safely download these https sites.
When running openssl s_client -showcerts -connect, it shows that root certum ca certificate uses RSA-SHA1 on these sites:
3 s:C = PL, O = Unizeto Sp. z o.o., CN = Certum CA
i:C = PL, O = Unizeto Sp. z o.o., CN = Certum CA
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA1
v:NotBefore: Jun 11 10:46:39 2002 GMT; NotAfter: Jun 11 10:46:39 2027 GMT
-----BEGIN CERTIFICATE-----
MIIDDDCCAfSgAwIBAgIDAQAgMA0GCSqGSIb3DQEBBQUAMD4xCzAJBgNVBAYTAlBM
MRswGQYDVQQKExJVbml6ZXRvIFNwLiB6IG8uby4xEjAQBgNVBAMTCUNlcnR1bSBD
QTAeFw0wMjA2MTExMDQ2MzlaFw0yNzA2MTExMDQ2MzlaMD4xCzAJBgNVBAYTAlBM
MRswGQYDVQQKExJVbml6ZXRvIFNwLiB6IG8uby4xEjAQBgNVBAMTCUNlcnR1bSBD
QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM6xwS7TT3zNJc4YPk/E
jG+AanPIW1H4m9LcuwBcsaD8dQPugfCI7iNS6eYVM42sLQnFdvkrOYCJ5JdLkKWo
ePhzQ3ukYbDYWMzhbGZ+nPMJXlVjhNWo7/OxLjBos8Q82KxujZlakE403Daaj4GI
ULdtlkIJ89eVgw1BS7Bqa/j8D35in2fE7SZfECYPCE/wpFcozo+47UX2bu4lXapu
Ob7kky/ZR6By6/qmW6/KUz/iDsaWVhFu9+lmqSbYf5VT7QqFiLpPKaVCjF62/IUg
AKpoC6EahQGcxEZjgoi2IrHu/qpGWX7PNSzVttpd90gzFFS269lvzs2I1qsb2pY7
HVkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEA
uI3O7+cUus/usESSbLQ5PqKEbq24IXfS1HeCh+YgQYHu4vgRt2PRFze+GXYkHAQa
TOs9qmdvLdTN/mUxcMUbpgIKumB7bVjCmkn+YzILa+M6wKyrO7Do0wlRjBCDxjTg
xSvgGrZgFCdsMneMvLJymM/NzD+5yCRCFNZX/OYmQ6kd5YCQzgNUKD73P9P4Te1q
CjqTE5s7FCMTY5w/0YcneeVMUeMBrYVdGjux1XMQpNPyvG5k9VpWkKjHDkx0Dy5x
O/fIR/RpbxXyEV6DHpx8Uq79AtoSqFlnGNu8cN2bsWntgM6JQEhqDjXKKWYVIZQs
6GAqm4VKQPNriiTsBhYscw==
OpenJDK version on Linux:
OpenJDK Runtime Environment (Red_Hat-11.0.17.0.8-2.el9) (build 11.0.17+8-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-11.0.17.0.8-2.el9) (build 11.0.17+8-LTS, mixed mode, sharing)
Here is the exception trace:
javax.net.ssl.SSLHandshakeException: Certificates do not conform to algorithm constraints
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:353)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:296)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:291)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:654)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:473)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:369)
at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)
at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:183)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1506)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1416)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:456)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:427)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:436)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
at myproject.Crawler.load(Crawler.java:127)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints
at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1681)
at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1606)
at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1550)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:638)
... 28 common frames omitted
Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on signature algorithm: SHA1withRSA
at java.base/sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:237)
at java.base/sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1677)
Seems that CentOS stream 9 overrides Java security policies on /usr/share/crypto-policies/DEFAULT/java.txt (accessible from /etc/crypto-policies/back-ends). Replaced JDK default jdk.certpath.disabledAlgorithms in the file resolved the issue!
Related
This issue is driving me a bit insane.
I am trying to configure an openLDAP Proxy to an Active Directory, which works fine as long as I use unencrypted ldap to the AD. But I would like to secure the connection between the proxy and the AD via LDAPs.
What drives me crazy is that this worked before until I enabled LDAPs for the proxy itself. Now I can't get it running, even if I undo my changes.
This is how the slapd.conf looks like:
# Include schemas
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/local.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
modulepath /usr/lib/openldap
modulepath /usr/lib64/openldap
moduleload back_ldap
moduleload rwm
loglevel 256
#LDAPS Settings
TLSCipherSuite HIGH:MEDIUM:-SSLv3
TLSCertificateFile /etc/openldap/cacerts/server.crt
TLSCertificateKeyFile /etc/openldap/cacerts/server.key
TLSCACertificateFile /etc/openldap/cacerts/CAs.pem
### Database definition (Proxy to AD) #########################################
database ldap
readonly no
protocol-version 3
rebind-as-user
uri "ldaps://ad-server.internal.de:636"
suffix "dc=ad,dc=internal,dc=de"
Now when I search I get the below error (ldaps or ldap).
Both queries work just fine when I change the uri to "ldap://ad-server.internal.de:389"
ldapsearch -h localhost:389 -D "CN=admin,OU=User,DC=ad,DC=internal,DC=de" -W -b DC=ad,DC=internal,DC=de '(objectclass=person)'
ldapsearch -H ldaps://localhost:636 -D "CN=admin,OU=User,DC=ad,DC=internal,DC=de" -W -b DC=ad,DC=internal,DC=de '(objectclass=person)'
=>
ldap_bind: Server is unavailable (52)
additional info: Proxy operation retry failed
This is not a certificate error, as the direct ldapsearch from the same host works just fine:
ldapsearch -H ldaps://ad-server.internal.de:636 -D "CN=admin,OU=User,DC=ad,DC=internal,DC=de" -W -b DC=ad,DC=internal,DC=de '(objectclass=person)'
This is what the log looks like:
Jun 09 12:06:06 adproxy.internal.de slapd[94952]: conn=1000 fd=12 ACCEPT from IP=127.0.0.1:47458 (IP=0.0.0.0:389)
Jun 09 12:06:06 adproxy.internal.de slapd[94952]: conn=1000 op=0 BIND dn="cn=admin,ou=User,dc=ad,dc=internal,dc=de" method=128
Jun 09 12:06:06 adproxy.internal.de slapd[94952]: conn=1000 op=0 ldap_back_retry: retrying URI="ldaps://ad-server.internal.de:636" DN=""
Jun 09 12:06:06 adproxy.internal.de slapd[94952]: conn=1000 op=0 RESULT tag=97 err=52 text=Proxy operation retry failed
Jun 09 12:06:06 adproxy.internal.de slapd[94952]: conn=1000 op=1 UNBIND
Jun 09 12:06:06 adproxy.internal.de slapd[94952]: conn=1000 fd=12 closed
Any idea why this happens would be greatly appreciated.
Edit:
I did some more digging and it actually seems to be a certificate problem. The tcpdump for the connection returns this error:
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unknown CA)
The AD certificate is self signed and unfortunately I have no saying in that, so I cannot change that.
In the standard config I get the same error when running ldapsearch. I can get ldapsearch running with two methods:
Set TLS_REQCERT never in ldap.conf
Set environment variable LDAPTLS_REQCERT=never
I know this is not ideal but this is not supposed to be the final configuration, I just want to get it running first.
However slapd seems to ignore both, because I still get the same error in the tcpdump and slapd debugging still gives me the following:
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 0, err: 20, subject: /CN=ad-server.internal.de, issuer: /CN=ad-server.internal.de
TLS certificate verification: Error, unable to get local issuer certificate
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: SSL_connect:error in error
TLS trace: SSL_connect:error in error
TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate).
I tried to add the self-signed certificate to the ldap.conf and to the trusted anchors for openssl, but both didn't work. I also noticed that I cannot get openssl to verify the self-signed certificate, while I can do the same on my PC...
My PC:
$ openssl version
OpenSSL 1.1.1h 22 Sep 2020
$ openssl verify server.crt
error server.crt: verification failed
CN = ad-server.internal.de
error 18 at 0 depth lookup: self signed certificate
$ openssl verify -CAfile server.crt server.crt
server.crt: OK
While on the server (REHL 7.9):
$ openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017
$ openssl verify server.crt
server.crt: CN = ad-server.internal.de
error 20 at 0 depth lookup: unable to get local issuer certificate
$ openssl verify -CAfile server.crt server.crt
server.crt: CN = ad-server.internal.de
error 20 at 0 depth lookup: unable to get local issuer certificate
The result on my PC is the expected behaviour for self-signed certificates, as far as I know. I already checked, but it is the latest version available on RHEL 7.9
So does anyone have any idea how I can
get SLAPD to honor the TLS_REQCERT or LDAPTLS_REQCERT settings OR
openssl to verify the self-signed certificate
Thank you!
I finally found a possibility to ignore the certificate validation error. Which is not the optimal solution, but due to the self-signed certificate and the openssl issue in the RHEL7.9 version, I am for now content to have it running at all. The final solution should then be to make the AD department get a certificate from our CA, though I don't know if I can convince them to do so.
So while the LDAP proxy seems to ignore the TLS_REQCERT none setting in the ldap.conf, there is a possibility to do this directly in slapd.conf:
### Database definition (Proxy to AD) #########################################
database ldap
readonly no
protocol-version 3
rebind-as-user
uri "ldaps://ad-server.internal.de:636"
suffix "dc=ad,dc=internal,dc=de"
tls start tls_reqcert=never
The last line eliminates the verification error.
Below is the problem:
I compiled apache http server 2.4.34 with Openssl 1.0.2p.
When I use the ciphersuite supporting TLSv1.2, TLSv1.1, TLSv1(Intermediate compatibility), It works.
But I get below error when I use high security CipherSuite supporting only TLSv1.2(Modern Compatibility).
Error in apache debug logs:::
SSL Library Error: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher -- Too restrictive SSLCipherSuite or using DSA server certificate
Ciphersuite(Modern) from "https://wiki.mozilla.org/Security/Server_Side_TLS":::
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
Please help me solve this issue.
The client does not have your RSA certificate
I have read endless posts on certification error that basically say either turn off validation or fix you certificate. In our project however we really what to use the certificate, but we can't get it to work. The SA and 2 programmers have been try everything we can think of and nothing is working. So clearly we don't know what we are doing.
First, This is the error we get on a simple connection and get perl program. WEBHOSTNAME replace real web hostname.
perl -MIO::Socket::SSL=debug30 testerTut2.pl
DEBUG: .../IO/Socket/SSL.pm:1784: new ctx 46260896
DEBUG: .../IO/Socket/SSL.pm:446: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:448: socket connected
DEBUG: .../IO/Socket/SSL.pm:466: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:501: using SNI with hostname WEBHOSTNAME
DEBUG: .../IO/Socket/SSL.pm:524: set socket to non-blocking to enforce timeout=10
DEBUG: .../IO/Socket/SSL.pm:537: Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:547: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:557: waiting for fd to become ready: SSL wants a read first
DEBUG: .../IO/Socket/SSL.pm:577: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:1772: ok=0 cert=46303216
DEBUG: .../IO/Socket/SSL.pm:537: Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:1408: SSL connect attempt failed with unknown error
DEBUG: .../IO/Socket/SSL.pm:543: fatal SSL error: SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
DEBUG: .../IO/Socket/SSL.pm:1821: free ctx 46260896 open=46260896
DEBUG: .../IO/Socket/SSL.pm:1826: free ctx 46260896 callback
DEBUG: .../IO/Socket/SSL.pm:1829: OK free ctx 46260896
500 Can't connect to WEBHOSTNAME:443 at testerTut2.pl line 34.
This is the perl program:
#!/bin/perl
require LWP::UserAgent;
use LWP::Protocol::https;
#note USERNAME is where the real account name goes
my $ua = LWP::UserAgent->new( ssl_opts => { verify_hostname => 1, SSL_ca_file => '/home/USERNAME/ca-bundle.crt'});
$ua->timeout(10);
$ua->env_proxy;
#note hostname is where the real web host name goes
my $response = $ua->get('https://hostname/tut/ops/data/newtut.dat');
if ($response->is_success)
{
print $response->content;
print $response->decoded_content; # or whatever
}
else
{
die $response->status_line;
}
The SA has made a signed certificate on the web server. Again webhostname would be replaced with real web hostname.
openssl s_client -connect lomweb01:443 -showcerts
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
CONNECTED(00000003)
depth=0 C = US, ST = MD, L = Greenbelt, O = NASA, OU = MMS, CN = webhostname.edtfmmslinux.ecs.nasa.gov
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = MD, L = Greenbelt, O = NASA, OU = MMS, CN = webhostname.edtfmmslinux.ecs.nasa.gov
verify return:1
---
Certificate chain
0 s:/C=US/ST=MD/L=Greenbelt/O=NASA/OU=MMS/CN=webhostname .edtfmmslinux.ecs.nasa.gov
i:/C=US/ST=MD/L=Greenbelt/O=NASA/OU=MMS/CN=webhostname .edtfmmslinux.ecs.nasa.gov
-----BEGIN CERTIFICATE-----
MIIDbDCCAlQC etc etc k7Pr1nRQG
3/NKQVqaSITGHGZBtlKjpw==
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=MD/L=Greenbelt/O=NASA/OU=MMS/CN=webhostname .edtfmmslinux.ecs.nasa.gov
issuer=/C=US/ST=MD/L=Greenbelt/O=NASA/OU=MMS/CN=webhostname .edtfmmslinux.ecs.nasa.gov
---
No client certificate CA names sent
---
SSL handshake has read 1639 bytes and written 711 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 921941EFFB19FA3158C751D155C012D5A418425BFAE94FEA1D99231A3CEF5D3C
Session-ID-ctx:
Master-Key: 13BFF7BE2B8ED18056BA54415026FC1ED133F47BADE2683A5EB3A2FED15F34ABD3F837985A498404A948B7F5B1F4774B
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - d6 99 6e 28 8c 86 5e 9b-e2 e8 etc. etc.
00b0 - 20 96 ea 05 9
Start Time: 1466432096
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
On the client box I created a local ca-bundle.crt file in the USERNAME home directory. I "cp /etc/pki/tls/certs/WEBSERVER.crt ~/ca-bundle.crt" and had the perl script set the SSL_ca_file value to its path.
The Apache configuration file was update to use the /etc/pki/tls/cert/WEBSERVER.crt file and restarted.
And it still doesn't work. We have tried different web host name patterns but there is no change. We have no idea why the certificate is not working, but we think we are following the instructions correctly. Firefox is happy after we accept the certificate but perl is not. So what are we doing wrong?
After stracing the perl script it turned out to be sybase. The sybase client comes with an incompatible version of openssl. Net::SSLeay is an interface to openssl. IO::Socket::SSL uses Net::SSLLeay, LWP::UserAgent uses IO::Socket::SSL. When the perl script is run, the PATH has sybase directories in the front. sybase has its own CA files that are not compatible/out of date with the CA RHEL 7 and it reads the sybase CAs first messing everything up by the time it gets to ca.pem. To fix the problem we changed the perl script to strip out the sybase directories from PATH and then the SSL_ca_file option then works fine.
my $ua = LWP::UserAgent->new( ssl_opts => { verify_hostname => 1, SSL_ca_file => '/home/<server account>/certs/ca.pem'});
This is the second sybase side effect we have had since going to RHEL 7. The other one was sybase in increasing file descriptors limits to 4096 vs. the standard 1024 causing a boundary overflow in an array that was hard coded to 1024.
I am trying to configure Zimbra on my Linode (ubuntu). It's been more than 12 continuous hours but I am unable to get it configured correctly. I have followed too many guides from internet already. For the last try, I was trying this: Configure Zimbra and as usual the same error occured. This is the error:
Installing Proxy SSL certificate...done.
Initializing ldap...failed. (28416)
ERROR
Configuration failed
Please address the error and re-run /opt/zimbra/libexec/zmsetup.pl to
complete the configuration.
Errors have been logged to /tmp/zmsetup05102015-071817.log
And this is the last few lines of log file:
Sun May 10 07:22:20 2015 done.
Sun May 10 07:22:20 2015 Installing LDAP SSL certificate...
Sun May 10 07:22:20 2015 *** Running as root user: /opt/zimbra/bin/zmcertmgr deploycrt self
** Saving server config key zimbraSSLCertificate...failed.
** Saving server config key zimbraSSLPrivateKey...failed.
** Installing mta certificate and key...done.
** Installing slapd certificate and key...done.
** Installing proxy certificate and key...done.
** Creating pkcs12 file /opt/zimbra/ssl/zimbra/jetty.pkcs12...done.
** Creating keystore file /opt/zimbra/mailboxd/etc/keystore...done.
** Installing CA to /opt/zimbra/conf/ca...done.
Sun May 10 07:22:25 2015 done.
Sun May 10 07:22:25 2015 Installing Proxy SSL certificate...
Sun May 10 07:22:25 2015 *** Running as root user: /opt/zimbra/bin/zmcertmgr deploycrt self
** Saving server config key zimbraSSLCertificate...failed.
** Saving server config key zimbraSSLPrivateKey...failed.
** Installing mta certificate and key...done.
** Installing slapd certificate and key...done.
** Installing proxy certificate and key...done.
** Creating pkcs12 file /opt/zimbra/ssl/zimbra/jetty.pkcs12...done.
** Creating keystore file /opt/zimbra/mailboxd/etc/keystore...done.
** Installing CA to /opt/zimbra/conf/ca...done.
Sun May 10 07:22:30 2015 done.
Sun May 10 07:22:30 2015 checking isEnabled zimbra-ldap
Sun May 10 07:22:30 2015 zimbra-ldap is enabled
Sun May 10 07:22:30 2015 Initializing ldap...
Sun May 10 07:22:30 2015 *** Running as zimbra user: /opt/zimbra/libexec/zmldapinit
Connection refused at /opt/zimbra/libexec/zmldapinit line 138.
Sun May 10 07:23:13 2015 failed. (28416)
Sun May 10 07:23:13 2015
ERROR
I am not sure, what can be wrong or how to fix it. If any of you have ever faced such problem and know the solution, please let me know.
Thanks
Begin by checking the /tmp/zmsetup05102015-071817.log and then do you have any services that could prevent ldap starting? moreover any ports that may already be in use preventing this?
I am failing a server security scan on Windows 2008 R2, with
TLS Protocol Session Renegotiation Security Vulnerability TLS SSL Man In The Middle CVE-2009-3555
The scan results recommend an upgrade to openssl 0.9.8l or higher.
I am using the latest version of tcnative-1.dll (1.1.29 13/02/14) which, as I understand it is built using the native libraries and openssl libraries.
Is the only way I can resolve this is to build tcnative myself with the latest version of openssl?
Looking at the http://tomcat.apache.org/native-doc/ build section I need MS Visual Studio (which I don't have and have never used).
Has anybody else build it? If so I cannot find it.
This result is a false positive. I've performed various tests with various versions of Tomcat using the 1.1.29 APR/native connector and in none of those test did insecure renegotiation occur.
Note that Tomcat - depending on version, connector and configuration may support secure renegotiation.
The most definitive test was with OpenSSL 0.9.8.k (i.e. a version of OpenSSL that is vulnerable to CVE2009-3555 and will attempt an insecure renegotiation). When I try this, the connection blocks and eventually times out.
You need to find a better security scanner.
For completeness, the output of the test was:
$ ./openssl s_client -connect 192.168.23.9:8443
CONNECTED(00000003)
depth=1 /C=US/CN=ca-test.tomcat.apache.org
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=US/CN=localhost
i:/C=US/CN=ca-test.tomcat.apache.org
1 s:/C=US/CN=ca-test.tomcat.apache.org
i:/C=US/CN=ca-test.tomcat.apache.org
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDSTCCAjGgAwIBAgICEAMwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCVVMx
IjAgBgNVBAMTGWNhLXRlc3QudG9tY2F0LmFwYWNoZS5vcmcwHhcNMTMwMjI4MDUy
ODQyWhcNMTUwMjI4MDUyODQyWjAhMQswCQYDVQQGEwJVUzESMBAGA1UEAxMJbG9j
YWxob3N0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5295PxiHkd0n
mDQkeVhH+cJpK9hbwOC7SlfWALW7arBmhFy48BIKJycynIIqLw9pd6bpDd9kMVHA
QR7c1HRRnKO4URNYc+4hnPljghvCLEnDCXD/qfOvogwLYC9q26UBRT40kI5naetF
8zQphds5ipnCD3IVIf1UNaZ7pzDLHk09MiTGS4RPX2D/ZF5oytj63ph9QARgt65Q
7MiMrt2UgUEYWwNjDysCYwqVau1+aOa21VbpTmDqHZVYM76iElXLf5zElwvbwJQJ
KrOf4Wt4DWMaQdVr29hIWQSI0RHV50UoDnwbeHUgff9/4dbq5MVRd0FCMEv/KTM9
iViUaVtwJwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVu
U1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUMNurcJQ0yv11RqvO
4kqpnnS8abswHwYDVR0jBBgwFoAUsDu8yfooXz4EH5tsx4to2AGw+D0wDQYJKoZI
hvcNAQEFBQADggEBAKvT5ys1022fhypkWPFhy1aohCJ5rA1oH1UN3RYWcsSpdSoO
+LFzaMnuQ9hc+gddP0H7FBe+ZCHYHiVnkrLFu0MdlrbTvRzhpMfu4zcLkhRWyq2o
dluAyUKMifFCboz7odeY1W1Jmf629sbzzI8GVG4C9Y9L8YasFJNsdCUmRHpbgjxX
1uUUbrcpU+RAei8QXf8of+XlVGw4+rknlyppYLpKWihlsYHgt6F01uYHgW24WcNF
vXyoF2cf/FIabJCHTaGYUYwpaoTZDSSohmpearf5J5tSN5a1/ZQRysTZbWmB+pY0
Yzp8SS0GSK6xFFkSKY5ZPQOZQpDmgt8Iz9d37AA=
-----END CERTIFICATE-----
subject=/C=US/CN=localhost
issuer=/C=US/CN=ca-test.tomcat.apache.org
---
No client certificate CA names sent
---
SSL handshake has read 2433 bytes and written 322 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: E98ED9D885D761C7B23AF93DC15C53D0680AF2D8345A37699549E48C9D4E18AE
Session-ID-ctx:
Master-Key: FA2C87FB24C68186D1CC63FEEF459B7DE4BA0F304D60F2293AB3C1C23DF03566F51DDB61A9576A1FE9C021CB3438B4C7
Key-Arg : None
Start Time: 1395309769
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
GET / HTTP/1.0
R
RENEGOTIATING
7087:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: