We have an Oracle application (Agile PLM) which is deployed in a clustered environment. We have one admin node and two managed nodes supporting our application, where admin and 1 managed nodes are on the same server. We also have Load balancer which manages the traffic between the cluster.
We want to configure SSL in our application so that the application URL will be accessible over https only. We have already configured SSL at Load Balancer level(by installing security certificates in weblogic server which is the admin server) but want to know if we have to configure SSL on the managed server as well or bringing Load Balancer on https is sufficient?
All the users access the application using the Load Balancer URL only but since I am from the development team, so is only aware of the fact that we can also connect to the application with Managed server URLs, which are still running on http. Is it must to bring Managed servers also on https or it is just a good practice but not necessary?
It's not necessary, though probably a good practice.
I believe I have read in Oracle's installation guide that the recommended way is HTTP on the managed servers and terminating SSL on the load balancer. This may have changed.
For what it's worth, I leave HTTP on the managed servers.
Related
I have a client site set up on AWS with multiple servers running HTPPS behind an Elastic Load Balancer. At some point, someone from the client's team attempted to update the SSL Cert by installing a new one directly on one of the servers (instead of in the ELB).
I was able to upload a new cert to the ELB, but when traffic is directed towards the server with the improperly installed cert, it triggers a security warning.
No one can seem to answer who attempted this install, how they went about, or where they installed it.
What's the best way to go about finding and removing it?
Thanks,
ty
If it's installed on the server, it has very little to do with AWS. I see you tagged the question with apache so I assume the server is running Apache Web Server. You will have to connect into that server and remove the SSL settings from the Apache Web Server configuration, just like you would with an Apache Web Server install anywhere else.
I'm on Weblogic AS 10.3.5, I have two managed servers pointed to a cluster, so I have two url, one for the first managed server, the other one for the second.
I will deploy my application on the cluster, so will I reach it on both the url? will the application deployed and running on both the servers?
How does it work? Can you give me some references, please?
Is it clear?
Thanks a lot!
First, you shouldn't be using WebLogic 10.3.5 anymore since it has reached the last stage of support called Sustained Support. Consider to upgrade at least to WebLogic 10.3.6.
Related to your question, I believe you are talking about a Web Application and how to access it. First you need to read about Load Balancing in a Cluster. For the web part (JSP and Servlets) basically you have to options: setup a Web Server (like Apache HTTP) to make use of the WebLogic Plug-in, that will then be connected to the WebLogic cluster. The other easier option is to simply use an LBR (load balance router hardware).
These are the "software" solutions you have for Load Balancing your web application in a clustered WebLogic:
WebLogic Server supports the following Web servers and associated
proxy plug-ins:
WebLogic Server with the HttpClusterServlet
Netscape Enterprise Server with the Netscape (proxy) plug-in
Apache with the Apache Server (proxy) plug-in
Microsoft Internet Information Server with the Microsoft-IIS (proxy) plug-in
You can read more about this options at the Configure Proxy Plug-ins documentation page for WebLogic 10.3.6.
when https is used on openshift, is my tomcat behind an apache server?
I mean does my clients connect to my tomcat directly or they connect to the apache server, and then the apache server connect to my tomcat through AJP connector?
If apache is the man in the middle, then I will not get my clients' IP address directly, but with x-forward http header. And I lose the control over certificate verification and trust management. At present, I am using mochahost's server. https does not get to my tomcat, but intercepted by an apache. I hate this.
Previously, I used another hosting service, even 2 apache servers are at front of my tomcat server. Even more ridiculous that 2 apache servers and my tomcat servers are on the same machine. This kind of configuration can only show the system architecture does not have the right ability to manage the whole thing.
By the way, I am talking about the Bronze/Silver plan. I guess Openshift is not different though I have not tried it yet. Anyone has a clear answer to my question?
https is against the man in the middle, but with tomcat server, in this world, there is no service that you can avoid the man in the middle. It is not because technology does not allow, but the people in charge does not really understand the thing, so not able and not willing to provide the right service.
I want to ask: if you use tomcat server, is there any hosting service provider who does not act as a man in the middle? No. There is none on this world at present (May 2014)!
jack
There is an apache reverse proxy located in front of your tomcat instance that does ssl termination. The Apache instance is at the node level, then tomcat runs on your gear.
Context
I developed an application deployed in a Glassfish 3.1. This application is accessed only by https and sometimes it must connect to third-party webservices located out the customers networks. The customer have other applications inside his network; mine is only a new one "service".
Topology approximation
Big-ip F5 is the ssl end point. The customer have in this device the valid certificate
IIS redirects by domain to the respective service
glassfish is the machine with the application (over, of course, a glassfish 3.1)
How it works
When a user try to connect to _https://somedomain the request arrives to the F5 where the SSL encryption ends; now we have a request to _http://somedomain. In the next step F5 redirects this request to the IIS and this, finally, redirects to glassfish. This petitions are successfully processed.
Points of interest
I've full control over glassfish server and S.O. of the vm where it is located. Not other applications are or will be deployed on this server; it's a dedicated server for the app and some services it needs. The Glassfish runs on a VM with a Debian distribution as S.O. This VM is provided by a VM Server but I don't know the brand, model, etc. The glassfish have the default http listeners configuration.
I don't have any more information about network and other devices and i can't access to
any configuration file of any other device. I can't modify any part of the network for my own but maybe ask, suggest or advice for a change. Network's behavior should not change.
Actually users reach the application without problem.
The used certificate is a simple domain certificate trusted by Verysign
The customer have no idea of how to solve this.
The problem
All the third party WS the application must access have an unique https access and, in some cases, the authentication required is mutual (two-way) and here we find the problem. When the application wants to connect to WS with mutual ssl authentication it sends the glassfish local keystore configuration targeted certificate. Customer wants, if possible, use the same cert for incoming and outcoming secure connections. This cert is in the F5 and i can't add to the glassfish keystore because if I do this I would be breaking Verysign contract requirements. I've been looking for a solution at google, here(stackoverflow), jita,... but only incoming traffic solutions I've found. I understand that maybe a SSL proxy is required but I haven't found any example or alternative solution for the outcoming ssl connections.
What I'm asking for
I'm not english speaker (isn't obvious?) and maybe i doesn't use the correct terms in my search terms. I can understand that this context can be a nightmare and hard to solve but I will stand... The first think I need is to know if exists a solution (or solutions) for this problem and if it (or they!) exist where or how can I find it/them. I've prepared different alternatives to negotiate with the customer but I need to known the true. I've spent tones of hours on this.
There are a couple of solutions.
1)pay verisign more money for a second "license/cert". They will be happy to take your money for the "privilege". :)
2)Create a different virtual server listening on 443 which points to a pool that has your client's server address as the pool member. Then on the virtual server, attach a serverssl profile that is configured to use the same cert you are using for the incoming connections. Then the F5 would authenticate with the same cert along with your app server would not need a client cert installed. Also, if they need to initiate a session to you, you would have to setup a virtual server with a clientssl profile that uses the same cert and requires a client cert to connect.
If your destinations may not be static addresses, then an irule(s) would have to be created to deal with that. Can be handled in 10 or later code with a DNS call in the irule and setting a node for the session to go.
I'm working on a site that exposes endpoints over HTTP and HTTPS through Azure Web roles.
We've done some updates to the database, and to force the sites to re-populate their cache we've rebooted the roles. Now, however, the SSL endpoints no longer work - connections to the server are broken.
We've tried reimaging the instances, which also didn't help.
Answering my own question to serve as reference for the future:
We'd removed the certificate used for Remote Desktop access to the site.
Interestingly, this caused the SSL side of the site to fail, but only on a reboot.
Our fix was to replace the certificate, then do a full redeploy to staging and a VIP swap.
It does appear that the load balancer is very sensitive to its certificate configuration. I've found before that if there's any issues with any of the certificates in a package that the load balancer just stops working with no error in the log.