"tlsv1 alert unknown ca" in node.js - node.js

For the last 5 days I've got a lot of weird errors in my app's logs. Here is the stack trace:
Error: 140428615087936:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:../deps/openssl/openssl/ssl/s3_pkt.c:1234:SSL alert number 48
at CleartextStream._pusher (tls.js:674:24)
at SlabBuffer.use (tls.js:217:18)
at CleartextStream.CryptoStream._push (tls.js:501:33)
at SecurePair.cycle (tls.js:898:20)
at EncryptedStream.CryptoStream.write (tls.js:285:13)
at Socket.ondata (stream.js:38:26)
at Socket.EventEmitter.emit (events.js:96:17)
at TCP.onread (net.js:397:14)
It is the same for all these errors. Node.js version is 0.8.24.
Does anybody know why it could happen?

We've solved that problem. It happened because of minor misconfiguration in SSL certificates on our other API server (which node.js talked to).
To check your SSL configuration you can use one service by SSL Labs. In our case there was this warning (incomplete chain issues):
To fix it you should do the following (excerpt from nginx docs):
Some browsers may complain about a certificate signed by a well-known
certificate authority, while other browsers may accept the certificate
without issues. This occurs because the issuing authority has signed
the server certificate using an intermediate certificate that is not
present in the certificate base of well-known trusted certificate
authorities which is distributed with a particular browser. In this
case the authority provides a bundle of chained certificates which
should be concatenated to the signed server certificate. The server
certificate must appear before the chained certificates in the
combined file:
$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
The resulting file should be used in the ssl_certificate directive:
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.chained.crt;
ssl_certificate_key www.example.com.key;
...
}
The key part is concatenation of certificate files. Errors in node.js app disappeared just after we've made that changes.

Related

openLDAP Proxy fails with ldaps

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.

gitlab SSL giving issues

I am trying to configure SSL in the GitLab (Latest) in centos 7 as per the document below:
https://docs.gitlab.com/omnibus/settings/nginx.html
But doing so I am encountering the below error:
4510076352:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:332:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 320 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
Looking for help.
I have used Let's Encrypt wild card certificate. The certificate is working fine for NGINX. But in Gitlab it's giving issues.

SSL Library Error: error: SSL routines:ssl3_get_client_hello:no shared cipher - Too restrictive SSLCipherSuite or using DSA server certificate

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

Azure Virtual Machine SSL for port other than 443

I cant seem to get secure content through port 8080 to an Azure VM.
Regular SSL traffic through port 443 is fine, However when setting an endpoint for port 8080 and then trying to access it I'm receiving the following error:
handshake to www.... failed. System.IO.IOException Authentication failed because the remote party has closed the transport stream.
Firewall Inbound and Outbound rules have been created.
Certificate is the same one that is being used for port 443 traffic without any issue.
thank you for your help.
the output from openssl s_client -connect is:
CONNECTED(0000019C)
27308:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:.\ssl\s23_lib.c:177:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 321 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
error in s_client
edit (solved):
The issues seems to be a bug in NodeJS. I downgraded from 0.10.29 to 0.10.26 and now everything works as expected.

Tomcat 7.0.52 APR 1.1.29 native TLS Protocol Session Renegotiation Security Vulnerability TLS SSL Man In The Middle CVE-2009-3555

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:

Resources