Getting "IDX10108: The address specified is not valid as per HTTPS scheme" when calling IdentityServer4 in AWS - ssl

We've implemented an Identity Server using IdentityServer4 and have deployed it to AWS. It works great until we enabled https on the ELB. Now when the client tries to authenticate we get the following error:
Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[0]
An unhandled exception has occurred while executing the request
System.InvalidOperationException: IDX10803: Unable to obtain configuration from: 'https://int.mycompany.com/.well-known/openid-configuration'. ---> System.ArgumentException: IDX10108: The address specified is not valid as per HTTPS scheme. Please specify an https address for security reasons. If you want to test with http address, set the RequireHttps property on IDocumentRetriever to false.
From what I've read the client is not happy with the certificate. This could possibly be related to the host name of the identity server and the name in the certificate. We have a valid wildcard certificate with subject "*.mycompany.com". We configured the client with Authority as "https://int.mycompany.com" so that seems to line up.
I've also read in these load balancing configuration that some headers have to be forwarded to the middleware but I'm not exactly sure how that would work.

Looks like HTTPS request are not recognized as such. Try to add the following settings into ConfigureServices method in the Startup class:
services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders = ForwardedHeaders.XForwardedProto;
});
From HTTP Headers and Elastic Load Balancing AWS documentation:
The X-Forwarded-Proto request header helps you identify the protocol (HTTP or HTTPS) that a client used to connect to your server. Your server access logs contain only the protocol used between the server and the load balancer; they contain no information about the protocol used between the client and the load balancer. To determine the protocol used between the client and the load balancer, use the X-Forwarded-Proto request header. Elastic Load Balancing stores the protocol used between the client and the load balancer in the X-Forwarded-Proto request header and passes the header along to your server.

Related

Putting AWS cloudfront in front of ec2 throws 502 error

I am trying to add SSL to my EC2 instance that hosts my API's in a node.js server by:
1) Provisioning a certificate from Certificate Manager
2) Putting Cloudfront in front of my EC2 instance
3) Adding record set in Route53
Before I actually added the record set in Route 53, I made a GET request via postman to my health check api
GET cloudfrontdistro.cloudfront.net/health
And the response was a 502 with the message
We can't connect to the server for this app or website at this time. There might be too much traffic or a
configuration error. Try again later, or contact the app or website owner.
Relevant details about my Cloudfront distro:
I used a Custom SSL Cert - the one that I got from ACM)
TLSv1.2_2018 security policy
Origin domain name is ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com
Minimum origin SSL protocol is TLSv1
Origin protocol policy is HTTPS Only
HTTP Port 80
HTTPS Port 443
Viewer Protocol Policy is Redirect HTTP to HTTPS
Allowed HTTP Methods are GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
Any help would greatly be appreciated! TIA!
I have similar problem Please look at this (https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-requirements.html).. One of the domain names in the certificate must match the domain name that you specify for Origin Domain Name. If no domain name matches, CloudFront returns HTTP status code 502 (Bad Gateway) to the viewer.

DNS a-route with SSL and Apache

I have a domain served at server A and I have set up an A-record to server B.
For http://mypage.com all works fine.
But there is also SSL on the domain. On server B there are a few virtual hosts set up. One of which has an SSL virtual host (443), theirpage.com. If I now go to https://mypage.com I end up at theirpage.com.
If I set up mypage.com MUST I have the SSL certificate from server A available for this new specific ssl-virualhost? The provider at server A does not share their ssl-certificates...
Assuming:
Server A - DNS only, no web services.
Server B - Web server.
The following is extreme oversimplification of what actually happens. For simplicity we exclude all caches, networking and application complexity.
What happens on the client:
User navigates to mypage.com (HTTPS)
Browser/OS does a lookup of who mypage.com is; receives the IP
Browser attempts to establish secure connection with IP of a webserver.
It is at this point browser will look at the SSL certificate provided by your web server. That certificate must be signed by trusted authority and have a valid alternate name of mypage.com. Not signed or name does not match to what user typed into the browser you will receive a certificate error.
If the certificate passed:
Browser will complete establishing connection
Browser will request a content named mypage.com
Browser displays content revived from the web server
In this scenario only web server must have a valid certificate, prooving to the client that it is indeed the server client attempts to connect to.
HTTP Scenario is similar, but connection is not secured and site will load. Most of the websites setup redirect request on HTTP calls, forcing the user's browser repeat it's request via HTTPS protocol.

HSTS header response processing over secured transport

As per the RFC6797-
[..] "An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport." [..]
https://www.rfc-editor.org/rfc/rfc6797#page-18
My question is - if the client is trying to access the host over non-secured HTTP (e.g. TCP port 80) and the server implements HSTS policy the server MUST respond with HSTS policy header over secured transport.
Now considering the secured transport as SSL - when does the SSL key exchange and handshake happen, for client to decrypt the server response over secured transport/SSL?
The https://www.ssl2buy.com/wiki/http-strict-transport-security-hsts-better-security-for-applications link nicely explains the HSTS policy implementation but I am unable to put it together how the SSL handshake happens.
HSTS has nothing to do with the SSL handshake.
It simply means if the browser is instructed to go to http://www.example.com, then instead act as if they were instructed to go to https://www.example.com.
The SSL negotiation happens afterwards - exactly as if they went to the https version directly.

WL-Proxy-Client-Cert header not sent

I m using Oracle HTTP Server as reverse proxy for WebLogic. I have set up SSL on both the proxy and the server with client certificate authentication. It works and the clients get authenticated by OHS, but i need to pass client certificate information to WebLogic so i can look at this certificate in my servlet. Documentation says that the proxy can forward client certificate within "WL-Proxy-Client-Cert" http header to the WebLogic server.
However, i can't get this to work. Within my servlet i tried both request.getHeader() and request.getAttribute() and getting null. I looked at both headers and attributes of the request objects and don't see anything like WL-Proxy-Client-Cert. In fact i don't see any headers starting with WL, only couple of headers starting with X-WebLogic, none of which has the certificate.
I did enable "Client Cert Proxy Enabled" option in Administration Console as described in the docs. Also i know that clients get authenticated since i see the certificate requested by the browser, after which i can successfully access the site.
Am i missing something?
I have finally got an answer from Oracle support on this. The problem was that i had to add one SSL directive to my virtual host configuration:
SSLOptions +ExportCertData
It goes under "IfModule ossl_module", right next to "SSLVerifyClient require" directive that specifies 2-way authentication for the proxy.
Note that after this, in the servlet, the certificate will be present in the usual "javax.servlet.request.X509Certificate" attribute, as if the server was doing client certificate authentication itself (no extra headers are received).
Also, note that you can have the server use 1-way SSL, if you feel secure with authentication done by the proxy, and you will still receive the certificate in the attribute in your servlet (in this case you should probably add a filter as they recommend to ensure the requests come from the proxy only). I have a feeling it will work even if the server port is regular http, though i haven't tested it yet.

HTTPS Web(only)Proxy

I just read over node-tls-proxy (http://code.google.com/p/node-tls-proxy/), a https proxy. I like the idea of it, but I'm not getting why this proxy needs a local http server (see the local-proxy.js script).
So I was wondering if this is necessary?
My idea of the proxy was actually like this: Client -> HTTPS Connection to trusted Server/Proxy -> Internets
In this case network sniffing between the Client and the Server wouldn't (hardly) be possible because it would be ssl encrypted.
Thanks,
Seb
If I get the idea correctly, the goal is to set up a "remote" proxy in a location that one trusts to be secure. Your client shall only communicate with this remote proxy using TLS, the remote proxy is then allowed to do the actual (no longer encrypted) HTTP requests.
What you do on the client side now is this: you configure the "local" proxy in your browser. Since you type "http://..." in your browser even when using the proxy, your browser will initiate an unencrypted HTTP connection to the local proxy first. Then the local proxy will open an encrypted TLS connection to the remote proxy and forward your request over a secured channel.
This means you need the local proxy for the purpose of "transforming" HTTP into HTTPS requests because your browser will dutifully only use HTTP when asked to make an actual HTTP request.