/build/static/layout/Breadcrumb_cap_w.png

Support portal http access

Hi Guys,

I've noticed that the user portal and the admin portal are both available on port 80 (http) and 443 (https://). Is there a way to setup the portal so it only uses https. I've noticed the force ssl option but I don't want to take the chance of breaking the agent if it can't communicate via ssl. I'm wondering what other people did you prevent portal access on http.

Cheers,

Mike

0 Comments   [ + ] Show comments

Answers (6)

Posted by: airwolf 13 years ago
Red Belt
0
K1000 Security Settings -> Forward port 80 to port 443.
Posted by: ms01ak 13 years ago
10th Degree Black Belt
0
Will that force the agent to report on https as well? I want the agents to have a fall back to port 80 just incase our ssl cert breaks. (We have no way of redeploying the agent if it breaks, because a lot of our units are standalone).
Posted by: airwolf 13 years ago
Red Belt
0
It's not disabling port 80, it's forwarding to 443. I haven't used SSL yet on the K1000, but I'm assuming the agents would be fine with port forwarding enabled. Just don't disable port 80 and you should be fine.

You may just have to try it out and see what happens with an agent trying to hit on 80.

This is a perfect example of why it's a BAD idea to have agent check-in ports identical to web UI access ports. One or both of them should be completely configurable. I want to be able to specify ALL agent ports and ALL web UI ports.
Posted by: GillySpy 13 years ago
7th Degree Black Belt
0
The agents will use 443 if it is available regardless of the setting that airwolf mentions. If your ssl cert "breaks" (e.g. expires) but 443 is still responding then the agent will not be able to communicate because it will be getting a response on 443. If your cert "breaks" and you turn off 443 (or block in on a firewall) then the agent will fall back to 80. Again, this agent behaviour is independent of your port forwarding setting above.

Once you remedy any problem with the cert, as long as the client is able to trust it and it matches the fully-qualified host name given in the client's amp.conf file and on the server then it will reconnect. If you ever wanted to change the fully qualified name of a ssl-enabled server (e.g. a company name change) then you could:
  1. change to using a SAN certificate that has both old and new name in it.
  2. or a wildcard
  3. or fall back to using port 80 (turn off 443 for a time) change the names which will only require DNS changes. This works for you because you are okay with them using 80
  4. or a script that will rewrite the amp.conf file. Clients will be disconnected until the server changes to match the client
Has anyone out there ever gone through a change like this? What did you do?
ms01ak, if I were you I'd get a virtual test environment so your comfortable with the permutations.
Posted by: ms01ak 13 years ago
10th Degree Black Belt
0
Hi Gilly,

So if I enable the settings on the server (forward port 80 to port 443) and let says the clients start dropping off because they don't like ssl . I could uncheck that settings and the agent will try 443 error out and then fallback to port 80?

Thanks,

Mike
Posted by: GillySpy 13 years ago
7th Degree Black Belt
0
Yes, if you uncheck 443 on the server then agents will try 80 at their configured hostnames (from client's amp.conf)
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ