We followed gudelines in the below link in order to secure the undertow http server (same steps have been followed for fuse 7.2 and we have the same issue).
https://access.redhat.com/documentation/en-us/red_hat_fuse/7.3/html/apache_karaf_security_guide/webconsole
When we start our server then we see entry "Starting undertow https listener on 0.0.0.0:8943". But when we try to visit link https://localhost:8943/hawtio then we get in chrome below error.
This site can’t provide a secure connection localhost uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol
The client and server don't support a common SSL protocol version or cipher suite.
Our certificate has been tested with the the undertow server of the wildfy and it works without any problem, so we believe that we have followed correctly the guidelines.
Also our rest services can exhange https messages without any problem.
In the below links you can find 2 configuration files.
https://quickfileshare.org/Yfx/org.ops4j.pax.web.cfg
https://quickfileshare.org/Yfy/undertow.xml
Have we overlooked any configuration step?
You have:
<w:engine
enabled-cipher-suites="TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
enabled-protocols="TLSv1 TLSv1.1 TLSv1.2 SSLv3.0" />
please verify if Chrome supports the above strong cipher suites.
Related
We are facing 502 error at our IIS web server, which used to work fine up to recently.
We had to change our reverse proxy machine: went from Ubuntu 18.04 to Ubuntu 22.04, and in this proccess the NGINX version changed from 1.21.3 to 1.18.0.
Right now, with NGINX 1.18.0, the 502 occurs. At NGINX log we see:
peer closed connection in SSL handshake (104: Unknown error) while SSL handshaking to upstream
The connection is being served with TLS v1.3, as informed by Mozilla Firefox 101.0.1 (64-bits).
We're working with a Windows Server 2012, which only accepts TLS up to v1.2 (https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-).
At upstream log there is nothing. If we go back to older NGINX the connection goes without problem (TLS is v1.2). So the problem seems to be at NGINX. We suspect it to be from TLS v1.3 (as per link provided), but couldn't manage to solve this.
We tried updating "nginx.conf" ssl_protocols TLSv1 TLSv1.1; but it didn't work, we still get TLS v1.3. We also tried to update NGINX (apt update and no version change) and some settings (proxy_ssl_name and proxy_ssl_server_name and proxy_pass) with no success either.
Any ideas on how to solve this?
Any ideas on how to solve this?
We're working with a Windows Server 2012, which only accepts TLS up to v1.2
Yup, you identified the problem right there.
Win8 won't support TLS1.3.
Yet you have a business need to communicate over TLS1.3.
Sounds like you want to swap some portion of your deployed software stack.
You could revert to your old Bionic Beaver,
but you're likely better off sticking with Jammy.
Time has moved on.
You want your stack components to keep up with a changing Internet.
We understood that the reason for the 502 error was NGINX didn't accept a private certificate while proxying the connection (our IIS had a private certificate - locally generated).
This case was closed by removing SSL from internal segment (between nginx and IIS), while keeping SSL v1.3 from the user/client to NGINX segment.
I am using a setup wherein a chain certificate(Root CA Cert-> Intermediate CA Cert -> Client Cert) is being sent to the Nginx. I need to configure Nginx in such a way that it forwards the entire certificate chain to the middleware. Right now, it is just sending the leaf certificate i.e. client certificate.
I found the following options from the Nginx's documentation (http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate)
1- $ssl_client_escaped_cert
2- $ssl_client_cert
None of the above returns the full certificate chain.
Is anyone aware if there is such an option available ?
This seems to be impossible by design - see https://serverfault.com/questions/576965/nginx-proxy-pass-with-a-backend-requesting-client-certificates
The usage of $ssl_client_escaped_cert (as explained in https://clairekeum.wordpress.com/2018/12/05/passing-client-cert-through-nginx-to-the-backend/) seems to be your only option.
This may not be a complete answer, but thought I'd post some resources that may give you a couple of ideas.
If you want the client cert details downstream, then one option is to avoid terminating Mutual TLS in nginx by using the stream module. Here is an example:
Mutual TLS Secured API Blog Post .
NGINX Config
In this setup there are 2 Mutual TLS connections being routed via nginx:
To authenticate with an Authorization Server - where Mutual TLS is not handled by nginx
To call an API with a certificate bound access token - where nginx terminates TLS
Note that this uses a LUA plugin and the ssl_client_raw_cert property to do the extra work of calculating a SHA256 thumbprint, which NGINX itself does not support.
Generally though it makes sense to externalise Mutual TLS plumbing from application level components, as in the above example. Eg you can forward ssl_client_eacaped_cert to your middleware, but perhaps nginx should do the more detailed work of checking issuers.
I have been looking for this for a while now. Still not sure if Envoy and Nginx does all the TLS stuff for a web-gRPC client.
In my case, my Nginx config works well with gRPC client and server. However, it is not working for web-gRPC client.
Nginx is no longer being actively supported for grpc-web. The default proxy for grpc-web is Envoy. You should be able to set up TLS by setting some config with the envoy.yaml file. In particularly, look under the 'tls_context' section.
I have applied a free certificate for my website and successfully installed the certificate in the certificate store. And the CN is the same as my domain(issued to mydomain).
I also set up the site bindings and added an https binding using the free certificate.
The port 443 is opened for both inbound and outbound.
Windows Network Troubleshooting detected the resource(my domain) is online but isn't responding to connection attempt.
But I still get ERR_CONNECTION_TIMED_OUT error from the browser.
Did I miss any steps? How could I enable the https in IIS?
UPDATE 11/14/2018
I have run bindings diagnostics and SSL diagnostics using JexusManager suggested by #Lex Li, and got more information as below:
Binding Diagnostics:
BINDING: https *:443:whatever.com
This site can take external traffic if,
TCP port 443 must be opened on Windows Firewall (or any other equivalent products).
Requests from web browsers must be routed to following end points on this machine,
[::1]:443.
My.private.IP.address:443.
This site can take local traffic at 127.0.0.1:443.
This site can take local traffic at [::1]:443.
Web browsers should use URL https://whatever.com:443. Requests must have Host header of "whatever.com".
Start DNS query for whatever.com.
DNS Query returns 1 result(s).
127.0.0.1
Binding Diagnostics does not verify certificates and other SSL/TLS related settings.
Please run SSL Diagnostics at server level to analyze SSL/TLS configuration.
And then I ran SSL diagnostics as below:
BINDING: https *:443:whatever.com
SSLCertHash: 2962cd5b2b450403bce520169c268de1f17a6216
SSL Flags: None
Testing EndPoint: 127.0.0.1
CertName: whatever.com
Version: 3
You have a private key that corresponds to this certificate.
Signature Algorithm: sha256RSA
Key Exchange Algorithm: RSA-PKCS1-KeyEx Key Size: 2048
Subject: CN=whatever.com
Issuer: CN=TrustAsia TLS RSA CA, OU=Domain Validated SSL, O="TrustAsia
Technologies, Inc.", C=CN
Validity: From 11/11/2018 4:00:00 PM To 11/12/2019 4:00:00 AM
Serial Number: 0B365B8ABC8118CD7F818FD5B7BB485C
DS Mapper Usage: Disabled
Archived: False
Subject Alternative Name: DNS Name=whatever.com DNS Name=www.whatever.com
Key Usage: KeyEncipherment, DigitalSignature
Enhanced Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1),Client
Authentication (1.3.6.1.5.5.7.3.2)
Basic Constraints: Subject Type=End Entity, Path Length Constraint=None
Certificate verified.
And, I also have run an SLL Checker and it returns:
whatever.com resolves to My.Public.IP.Address
Server Type: Microsoft-IIS/8.5
No SSL certificates were found on whatever.com. Make sure that the name resolves to the correct server and that the SSL port (default is 443) is open on your server's firewall.
The certificate passed the SSL Diagnostics but it has some problem. I didn't get it. How could I enable https protocol for my site? Many thanks!
Problem solved.
As #John Wu said, this is not a programming problem but a network gateway problem.
First, the certificate has no problem and so does the server/firewall setting.
The problem occurred in the network gateway of the cloud service provider that blocked the 443 port inbound and outbound. In my case, I am using AliCloud server and it blocked every request which went through 443 port from the public network. And this is why I could only get access to the SSL website through the browser on the server.
The solution is very simple. The only thing needs to do is to inform the cloud service provider to open the 443 port. In my case, I just added the 443/443 port authorization in the control panel of the cloud servers and then everything fixed.
We are using nginx for https traffic offloading, proxying to a locally installed jasperserver (5.2) running on port 8080.
internet ---(https/443)---> nginx ---(http/8080)---> tomcat/jasperserver
When accessing the jasperserver directly on its port everything is fine. When accessing the service through nginx some functionalities are broken (e.g. editing a user in the jasperserver UI) and the jasperserver log has entries like this:
CSRFGuard: potential cross-site request forgery (CSRF) attack thwarted (user:%user%, ip:%remote_ip%, uri:%request_uri%, error:%exception_message%)
After some debugging we found the cause for this:
In its standard configuration nginx is not forwarding request headers that contain underscores in their name. Jasperserver (and the OWASP framework) however default to using underscores for transmitting the csrf token (JASPER_CSRF_TOKEN and OWASP_CSRFTOKEN respectively).
Solution is to either:
nginx: allow underscores in headers
server {
...
underscores_in_headers on;
jasperserver: change token configuration name in jasperserver-pro/WEB-INF/esapi/Owasp.CsrfGuard.properties
Also see here:
header variables go missing in production
http://wiki.nginx.org/HttpCoreModule#underscores_in_headers
Answered it myself - hopefully this is of some use to others,too
I had this issue with Jasperserver 5.5 AWS AMI
More specific:
/var/lib/tomcat7/webapps/jasperserver-pro/WEB-INF/esapi/Owasp.CsrfGuard.properties
Change:
org.owasp.csrfguard.TokenName=JASPER_CSRF_TOKEN
org.owasp.csrfguard.SessionKey=JASPER_CSRF_SESSION_KEY
To:
org.owasp.csrfguard.TokenName=JASPERCSRFTOKEN
org.owasp.csrfguard.SessionKey=JASPERCSRFSESSIONKEY
My version of Jasperserver looked slightly different, the CSRFguard files are located in jasperserver/WEB-INF/csrf
I edited the jrs.csrfguard.properties file.