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.
Related
I've got CRC running on Windows 11 and I would like to connect there from a RHEL9 VM.
CRC listening on 127.0.0.1:6443
Port forwarding rule created on Win machine to fwd connections on 192.168.1.156 (local intf) to 127.0.0.1:
$ netsh interface portproxy show v4tov4
Listen on ipv4: Connect to ipv4:
Address Port Address Port
192.168.1.156 9000 127.0.0.1 6443
Added rule in firewall to allow connections to port 9000
From the VM:
[test#workstation ~]$ telnet 192.168.1.156 9000
Trying 192.168.1.156...
Connected to 192.168.1.156.
Escape character is '^]'.
Connection closed by foreign host.
[test#workstation ~]$ oc login -u developer -p developer https://192.168.1.156:9000
The server is using a certificate that does not match its hostname: x509: certificate is valid for 10.217.4.1, not 192.168.1.156
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y
Error from server (InternalError): Internal error occurred: unexpected response: 412
Any idea on how I can fix this and be able to connect from my VM towards CRC?
thanks
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.
I've looked at several similar questions here, but none of them have helped me. I want to connect to a web service that uses single-sign-on via an RSA SecurID keyfob. I start by trying to load any cookies provided by the initial GET request. Here's my command:
curl -A "Mozilla/5.0" -L -b cookies.txt -c cookies.txt -v -X GET \
https://sso.example.com/sso/login.htm
I get this in response:
* About to connect() to sso.example.com port 443 (#0)
* Trying 23.12.245.199... connected
* Connected to sso.example.com (23.12.245.199) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to sso.example.com:443
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to sso.example.com:443
Here's what I'm using:
# curl --version
curl 7.19.7 (x86_64-suse-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8j zlib/1.2.7 libidn/1.10
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
# more /etc/*-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3
# uname -r
3.0.101-0.21-default
Any ideas?
This is OpenSSL in your client that has a problem to understand what the server is saying and it errors out because of that.
You can sometimes work around these kinds of issues by forcing curl to speak SSLv3 (-3), TLS1.0 (-1) or even SSLv2 (-2)
... it is also conceivable that your severely outdated versions of curl and OpenSSL simply have a bug or two that cause this and that you can fix this problem by upgrading to modern versions (and then also fix the numerous security problems your versions contain).
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: