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
Related
I have on Windows server certificate which is valid and active and WinRM listener is active as well on port 5986 (telnet works) for WinRM connection that needs to be established from the Linux server.
I didn't copy that certificate anywhere on the linux server as I do not know where that should be or how it should be configured.
If I try to establish WinRM connection I am getting this error on the Linux server.
openssl s_client -connect 10.7.147.210:5986
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 1367 bytes and written 447 bytes
Verification error: unable to verify the first certificate
I tried by referencing CAfile and CApath and cert option but without success:
openssl s_client -cert winrmcert.pem -key winrmcert.key -CApath . -connect 10.7.147.210:5986
openssl s_client -CAfile winrmcert.pem -connect 10.7.147.210:5986
Can you please help me what I need to do and configure on Linux server for certificate generated on Windows server for WinRM connection? I am not the expert for this topic so I would appreciate all useful instructions. Thank you
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.
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.
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.
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: