I am using Axis2 and Rampart to develop a secure web service and deploy it on jBoss. After successfully deploying the service on jBoss, I and using SoapUI to test the service. I get following error:
wsse:InvalidSecurity
Expected transport is "https" but incoming transport found : "http"
How do I configure HTTPS transport using SoapUI?
Does your endpoint have http or https?
From rampart sample
Rampart enforces the use of HTTPS transport and that
{http://ws.apache.org/rampart/policy}RampartConfig assertion provides
additional information required to secure the message.
Expected result :
org.apache.axis2.AxisFault: Expected transport is "https" but incoming transport found : "http"
This sample uses http transport while the policy enforces https transport. Thus you
get a error message as mentioned above. You can find a complete tutorial on transport level
security here. http://wso2.org/library/3190
Your web service is probably using http when it should be using https.
Related
I want to map a domain with my spring websocket deployed on server(tomcat) over port 8090.
I need to access my application through proxy passing over apache 2.4 installed on centOS.
The application(.war file) is being accessed from a client build on
react and this client is on another server.
I followed each step of below article but it is not working in my case.
Getting below error :
WebSocket connection to 'ws://xyz/abc/greeting/251/lcnlhdwc/websocket' failed: Error during WebSocket handshake: Unexpected response code: 400
Please help me.
WebSockets and Apache proxy : how to configure mod_proxy_wstunnel?
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.
I have been trying to configure a simple pass through proxy using wso2 esb, which points to a REST service in https port.
I had tried doing the same using my development machine (Windows 7) and it is successful.
But when I try repeating the same in production server, in RHEL, I get The system cannot infer the transport information error in system log.
Things Tried
Created passthrough proxy service pointing to https://some.domain.in/something/something.
Tried CURL to https://some.domain.in/something/something and its shows the response properly
Imported certificate from the site to client-truststore.jks. Same was done locally and it worked.
in axis2.xml, edited <parameter name="HostnameVerifier">AllowAll</parameter>under https transporter
Error Message
When clicked in test in configuration console, I got the following message, Invalid address
CURL the proxy service URL, and got Empty response
Checked system logs and saw below logs
Am I missing out something?
I could see in the wso2-error-logs following messages
ERROR {org.apache.synapse.transport.passthru.TargetHandler} - I/O
error: handshake alert: unrecognized_name
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
Then I realised that I was using java 1.6 locally but 1.7 in production.
And in Java 1.7 there are some changes in SSL handling
The JDK 7 release supports
the Server Name Indication (SNI) extension in the JSSE client. SNI,
described in RFC 4366 enables TLS clients to connect to virtual
servers.
In order to bypass this, I added JAVA_OPTS="-Djsse.enableSNIExtension=false" in wso2server.sh and restarted.
This solved my problem.
Not sure if this is the correct way though
This url helped me finally
I want to write a WCF service (self-hosted) that should use https.
By searching the web I found a blog article from msdn that tells me
to use the "netsh.exe" command to bind the certificate to the endpoint
by commandline:
http://blogs.msdn.com/b/james_osbornes_blog/archive/2010/12/10/selfhosting-a-wcf-service-over-https.aspx
However, is this still state of the art?
Why not use this:
http://msdn.microsoft.com/de-de/library/system.servicemodel.description.servicecredentials.servicecertificate(v=vs.100).aspx
Or do I miss something?
Thanks for any help.
So I finally found out why I need to use the netsh command:
Check this article:
https://msdn.microsoft.com/en-us/library/ms789011%28v=vs.110%29.aspx
From this article:
If the transport is HTTP (using the WSHttpBinding), SSL over HTTP provides the transport-level security. In that case, you must
configure the computer hosting the service with an SSL certificate
bound to a port, as shown later in this topic. If the transport is
TCP (using the NetTcpBinding), by default the transport-level security
provided is Windows security, or SSL over TCP. When using SSL over
TCP, you must specify the certificate using the SetCertificate method,
as shown later in this topic.
So you can only use the Property for tcp binding.
If you use ssl over http, you need to bind a certificate to a port by netsh command
I'm using Spring Security for X.509 preauthentication.
To make sure the client sends its certificate per HTTP request, is it necessary to:
Modify pom.xml to set <wantClientAuth> and <needClientAuth> to true
Set Apache's SSLVerifyClient to require reference
Based on reading, the web server must tell the client-side to sends its certificate in order for the client to actually send it. I'm confused if Spring Security AND Apache configuration is required to achieve this.
Spring Security configuration has nothing to do with whether the client sends a certificate or not. That's decided at the SSL protocol level and hence by the negotiation between the client and the server. Your question is a bit unclear in that it refers to a maven pom and an Apache configuration without explaining how your system is set up. Are you running the maven Jetty plugin with an Apache server in front?
Spring Security's X.509 authentication won't work if the SSL connection doesn't terminate at the servlet container. So if you have HTTPS between the client and Apache, and a non-SSL connection from Apache to the servlet container, then the client certificate won't normally be available.
If you are using an AJP connector, then you can configure Apache to pass the certificate on to the back end using the ExportCertData option. If you aren't, you can still take the exported certificate and pass it as a request header (you'll find examples of this elsewhere on SO). You would also need to customize the Spring Security X.509 code to extract the certificate from the header, rather than the standard java property name which it uses by default.