I am trying to make a (non-simple) CORS GET request (AJAX) made by my client server (running on Apache # port 443) to a 3rd party endpoint server (running on Tomcat # port 8443), which fails to trigger when tried over HTTPS.
When SSL is not enabled it works just fine indicating that the CORS is set up properly.
The problem is that since the GET is (not-simple) it sends a pre-flight OPTIONS request.
According to this:
Pre-flight OPTIONS request failing over HTTPS
Pre-flighted requests don't include the client certificate. He states this is in the CORS spec however I was unable to find this specifically listed in the spec:
http://www.w3.org/TR/cors/
The third party cannot enable
SSLVerifyClient optional
as they require all communication be sent with SSL.
However they do have their CORS setup right and they have
access-control-allow-credentials: "true"
In our AJAX call we included in the xhrFields
withCredentials: true
So we are telling it to pass withCredentials (which includes cert / cookie / etc)
And on our APACHE we have
SSLOptions +ExportCertData
Somehow when we make the call though, they are still seeing the error "key/cert was not included "
Am I missing something? Is there a way to force this in Apache?
At the moment I'm getting ready to create a man the middle script to attach the cert to the initial request but it seems like there has to be a better way.
Any suggestions?
Related
I have a Tomcat server that is behind an NGINX reverse proxy applying SSL. There is a bearer token in place for API calls on the Tomcat server, but I am getting a 401 error when I send this token to an endpoint in Postman. The proxy otherwise works flawlessly.
I've spent way too long troubleshooting this, but I've only looked at my proxy settings. I discovered last night that the proxy should be forwarding Authentication headers to the upstream Tomcat server, so now I'm lost as to how to troubleshoot this. Has anyone encountered this before or can point me in the right direction? This is outside of my normal scope so I'm a little out of my element.
EDIT - Even when I force the header with the Bearer token using "proxy_set_header Authorization "Bearer $ID_TOKEN";" it still returns the 401 error. Is it maybe adding something it shouldn't like a second Authorization header, or appending the Authorization header?
EDIT2 - Tomcat error logs show:
[{"time":"2021-05-14 19:01:10.069","description":"Request header did not include a token."}]
If you are not using the auth_request module for NGINX then it should be fairly easy to simply pass the Authorization headers as followed:
proxy_set_header Authorization $http_authorization;
proxy_pass_header Authorization;
If this doesn't work i will really need to see more of your NGINX configuration and I would strongly suggest to use the NGINX auth_request module to handle all oAuth on the NGINX server itself.
I have enabled mod_http2 for the Apache Web Server, and made the necessary changes in the conf, still any request made from a browser to the server follows http/1.1 Protocol
The server sends a Upgrade:h2 header field but the browser still continues to make http/1.1 requests.
How can i make a h2 request from Mozilla/Chrome?
I'm using Mozilla Firefox 48.0
Check that HTTP/2 support is enabled in Firefox:
In the address bar of Firefox, type "about:config", then search for "network.http.spdy.enabled.http2" and make sure that it is set to true.
Firefox implements HTTP/2 only on TLS
So, you will have to access the website using https://xxxxx
Browsers currently only support HTTP/2 via https. See http://caniuse.com/#feat=http2 the note number 2.
The HTTP/2 standard imposes some extra requirements on https, no cipher from a specified black list may be used.
An acceptable Apache SSL configuration regarding this is:
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
SSLProtocol All -SSLv2 -SSLv3
This needs to be changed in the httpd config file and NS_ERROR_NET_INADEQUATE_SECURITY should not occur after httpd restart.
I have an Apache server that I'm attempting to send requests over HTTPS to, but I've been struggling to get past cross origin issues as well as issues using SSL.
I'm not exactly sure where the problem lies, as I seem to be getting different responses back from the web consoles (testing with Firefox + Chrome) concerning the failed request. In Chrome, I simply see that the request that is sent as a POST is changed to OPTIONS and notes that it failed without much else. In Firefox, I see the following two issues:
In the console, the request says it fails due to CORS:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://123.456.789.001. This can be fixed by moving the resource to the same domain or enabling CORS.
However, inspecting the failed request in the network tab shows the following issue about the certificate:
123.456.789.001 uses an invalid security certificate. The certificate is not trusted because it is self-signed. (Error code: sec_error_unknown_issuer)
After digging, I'm having issues determining what is actually causing the request to fail - is it because my CORS rules are not setup properly? Or is it because I'm attempting to send requests to a server that is using a self signed certificate and therefore not being trusted by my request/browser?
I believe CORS is setup properly on my end, here are the contents of the files I'm using to enable CORS:
Crossdomain.xml
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
.htaccess:
# Always set these headers.
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token, Access-Control-Allow-Origin, X-Frame-Options"
# Added a rewrite to respond with a 200 SUCCESS on every OPTIONS request.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
Obviously these settings aren't great for production, but after spending hours trying to pinpoint the issue, I went with some examples that were the least restrictive in terms of enabling CORS hoping I'd see the requests go through and then go back and edit them properly. However, I still see the Cross Origin errors in the console with these changes uploaded to the Apache server (and server restarted after files changed).
So is there anyway to tell if CORS or the self-signed certificate is causing the issue? I didn't necessarily want to go ahead and purchase a SSL certificate at this time since I'm still in development, and the site I'm using to host the content is forced to https, so I can't pass the requests over http.
I have an Apache server which uses SSL and requires client certificates for all incoming requests - all other requests are terminated immediately. This is fine in most cases but I would like to allow a CORS preflight to be sent to the server without client cert. The response to the preflight should be static.
Any ideas on how I can configure this in the Apache config?
I answered something that may be related here.
Basically put your auth or ssl stuff between <LimitExcept OPTIONS> and </LimitExcept>
I am currently using the apaches mod_proxy/mod_proxy_http/mod_headers as a forward proxy to add (overwrite) cookie request headers to a request like this:
<Proxy *>
Order deny,allow
Allow from all
RequestHeader set Cookie "mycookie=1234"
</Proxy>
(Of course i don't have allow from all and * but to simplify and reproduce this is just fine)
Now I want to do the same for an ssl connection. I loaded mod_proxy_connect which makes ssl work fine, but the header injection doesn't work.
This makes sense because SSL is end2end and shouldnt be modified on the way.
However I want to do it. I think the server would need to be a man in the middle. It would need its own SSL certificate which will be invalid for the domain, but this can be added as an exception. Can this somehow be done with a reverse proxy?
Another thing which i would be cool with to (which I would prefer) would be to map the ssl connection to a usual http connection.
Any suggestions welcome!
It is possible, but that is a breach of SSL security, so you won't find feature for this in white-hat software.
SSLStrip can proxy HTTPS to HTTP and transform links and redirects on the fly.