I have set up an HTTPS endpoint for my mulesoft flow which is working great in local.
https://'localhost':8081/customerquote
Once I deploy it on CloudHub I am not able to contact the url using https, the URL looks like
https://myappname.cloudhub.io/customerquote it is responding only in HTTP reporting an SSL handshake error of course.
Already tried to switch the endpoint port to 443 or 8443 without any results.
Any Idea ?
You need to use properties placeholders when you're deploying to CloudHub:
http://www.mulesoft.org/documentation/display/current/Developing+a+CloudHub+Application
If your application requires an externally accessible HTTP or HTTPS
port to receive messages, trigger events, or expose a web service or
user interface, you must declare the port using the reserved property
${http.port} or ${https.port}. On CloudHub, port ${http.port} or
${https.port} is assigned automatically by the platform services.
Traffic on port 80 to your application domain URL will be routed to
this port.
An HTTPS listener requires a TLS configuration.
Please refer this link
https://developer.mulesoft.com/docs/display/current/Building+an+HTTPS+Service
I did copy the exactly example reported here and it worked
http://www.mulesoft.org/documentation/display/current/Building+an+HTTPS+Service
Related
I have an existing web application hosted in Tomcat which is listening for a HTTP POST.
However for security reasons requests to the web application have to be transported across the network as HTTPS.
I cannot change the web application.
So I want to receive a HTTPS POST, decrypt it and pass it on to the web application as a HTTP POST.
I also need to pass back to the sender response codes etc.
I have been told that I can do this using Apache configured as a "reverse proxy".
But I am not an expert at Apache or Tomcat and before I investigate this option I wanted to be sure I was going down the right path.
i.e.
Schematic
So to the Remote Server application everything looks like it happens over HTTPS.
And to my local Tomcat web application everything looks like it happens over HTTP.
Is this doable and correct ?
Do I need to use Apache or could I do it all in Tomcat ?
Is this what is called "url rewriting" ?
This is more than just "redirection" ?
Thanks,
Brett
I have a custom coded relay server application in VB.NET that is currently deployed as a windows service.
It accepts HTTP web requests from a client using a Tcp Listener, parses the requests and forwards it to another remotely hosted service via socket communication. The result from the service is then sent back by my relay server to the original client as a http response.
This functionality works perfectly as of now, but I would now like to upgrade my relay server to accept HTTPS requests instead of http.
I am not sure how to move ahead with this scenario.
I researched and found the following 2 options but I am not sure which is better and feasible?
One, I explicitly upgrade my current code to handle https handshake, certificate validation etc (if so, how?) or second option, can my current application be hosted on IIS to handle this scenario (if so, how)?
Thanks in advance.
A possible solution is to use IIS with Application Request Routing (ARR) as a reverse proxy in front of your service (its not possible to "Host" your service in IIS as such).
You could setup IIS/ARR with a certificate and suitable HTTPS binding, then configure ARR to proxy the HTTPS requests onto your service listening on HTTP. No changes required to your service's code.
Take a look at the following example: https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing
In your case your service listening on port 80 is no different to a website running in IIS. The above example is more complicated than you need (as its reverse proxy'ing 2 websites based on a prefix of the URL), but it gives you a starting point.
A further possible step to force all traffic to use HTTPS would be to change the port your service uses (eg to 8080 instead of 80), then setup IIS to handle port 80 to perform a redirect to 443, and then use 443 and ARR to proxy your traffic to your service on 8080.2
I have an application that sends a request to a web service. Unfortunately the application is compiled and the link to the web service is embedded in the application as http. (Yes I know how dumb that is, I didn't write it)
Recently, the 3rd party company is no longer allowing http requests, everything must be https.
The application runs as a webapp on Tomcat. The server is a windows server.
Is there a way to intercept the call to this web service and force it to use https?
As you can't change the application's source code (as it is compiled), and you can't change the web service (as it is 3rd party) either, the only way to solve this problem is making a proxy between the application and web service. To do that, you need to (assume the proxy is running in localhost):
As the web service URL is embedded into the compiled application, in order to let application send HTTP request to our proxy, hosts mapping need to change (e.g. /etc/hosts) to override DNS. For example, if the HTTP request in application is GET http://example.com/api/sample, in /etc/hosts, example.com need to be mapped to 127.0.0.1.
Make a proxy web server in localhost and open the same port as the web service. This proxy is a very simple web server (any backend programming tech can do it), it is only responsible for request-forwarding. In this way, when application send HTTP request to example.com, it sends the request to the proxy server.
After receiving HTTP request from application, the proxy server extract the request URL/header/body and send HTTPS request to example.com's real IP address. Please note: in this HTTPS request, a header host whose value is example.com should be added. 3rd party web service may check this header.
After the real response is returned from example.com, proxy will return it to the application.
Of course, you can also use reverse engineering (Java Decompiler) to get the application's "source code", change the web service URL and then compile again to a webapp. However, as the application may need to update/upgrade and it is may not under your control, this reverse engineering method is not recommended.
You could use a proxy script. Write it in any server-side language you want, for example PHP, set the API URL to this script, the script does the https request for you and pass the results back to your app.
You could also use Apache itself as the proxy and use something like: Apache config: how to proxypass http requests to https
I come across a very strange position, I was working on a project in BizTalk, initially I had to consume WCF services deployed on http. Now after a lot of work done. They just updated their bindings to https. Now what is option for me. how I change my orchestration. When I try toupdate service send port (http to https). I receive following error message on Biztalk.
Please guide me how to cater with this issue.
Regards,
You need to change the Security mode property in the Security tab to be Transport (or TransportWithMessageCredential) if you want to use https.
I believe you'll need to use another port type, like WCF-Custom.
Assume I’m running a website ( on IIS7 ) listening for requests on port 8000. Now this website contains only static content ( ie html files ). So when I browse to URL http://localhost:8000, browser displays website’s default html page. But if I’m also running a self-hosting WCF service listening for requests on URL http://localhost: 8000 ( this WCF service isn’t hosted by IIS ), then browser instead displays data about WCF service:
a) Don’t know much about TCP/IP, but as far as I know only one application at a time can listen on particular IP and port, but here both the website and WCF service are able to listen on the same IP address and port number. How is that possible?
b) When I enter a local url ( say http://localhost:8000 ) into browser, doesn’t browser request a page via IIS? If so, then why does it display details of a WCF service and not a website’s default page? Afterall, this WCF service isn’t even hosted by IIS.
Thank you
It is true that normally, only a single process can listen on a specific socket. However, work was done in Windows to support this specifically for HTTP listeners, specifically with the introduction of HTTP.SYS in IIS 6.0.
Basically, with this it is the kernel that actually listens for the HTTP requests and then the connection is routed to one of multiple listener processes in user-land.
The WCF HTTP listeners for self-hosting rely on HTTP.sys as well, so they can share ports with IIS if needed (or across multiple self-hosted WCF services).