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
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)
Please log in to answer
Posted by:
ms01ak
13 years ago
Posted by:
airwolf
13 years ago
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.
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
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:
ms01ak, if I were you I'd get a virtual test environment so your comfortable with the permutations.
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:
- change to using a SAN certificate that has both old and new name in it.
- or a wildcard
- 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
- or a script that will rewrite the amp.conf file. Clients will be disconnected until the server changes to match the client
ms01ak, if I were you I'd get a virtual test environment so your comfortable with the permutations.
Posted by:
ms01ak
13 years ago
Posted by:
GillySpy
13 years ago
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.