AMP Rebind Bug/Error

┏━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Key                  ┃ Value                                   ┃
┣━━━━━━━━━━━━━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ Operating System     ┃ Windows - Windows Server 2019 on x86_64 ┃
┃ Product              ┃ AMP 'Callisto' v2.5.1.2 (Mainline)      ┃
┃ Virtualization       ┃ None                                    ┃
┃ Application          ┃ Application Deployment                  ┃
┃ Module               ┃ ADSModule                               ┃
┃ Running in Container ┃ No                                      ┃
┃ Current State        ┃ Indeterminate                           ┃
┗━━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

Problem Description:

SSL on AMP broke after an update. After redoing the SSL, the AMP Instance manager shortcut on the desktop only browses to http and not https. When trying to rebind ADS in the command line, it overrides to the default bind with http.

Are you using AMPs internal HTTPS or are you using a reverse proxy (IIS ARR / Caddy) ?

I am using AMP’s internal HTTPS with the certificate pointers in the ADS config file.

We don’t recommend doing this (we’re actually planning to deprecate the internal HTTPS implementation) and recommend instead that you set up a reverse proxy to handle HTTPS

Sure, however the “rebind” function isn’t working properly regardless, and a reverse proxy would still require ADS and its related instances to interpret http requests into https for certain applications. Additionally, internal HTTPS works perfectly fine from my experience, however it is simply that the bindings to the references in configs that refer to https and not http aren’t being respected.

There aren’t any known issues with rebind? If you have a reverse proxy handling AMPs HTTPS then AMP doesn’t have to handle serving HTTPS at all. There is a reason that on Linux system, AMP just sets up a reverse proxy as standard out-of-the-box when you ask for HTTPS and this is the recommended configuration - it’s just not something it can do by itself on Windows.

The GUI app and some components are definitely not aware of AMPs internal HTTPS implementation, so indeed the GUI app won’t be able to open the browser for you - you have to ignore that function and use the browser.

What I’d like to do is make it easier on Windows to automate HTTPS using Caddy or similar, if I can do that then I’ll be deprecating the internal HTTPS entirely shortly after.

I see. Unfortunately, I am having issues with the rebind as it doesn’t rebind at all and forces the default configuration, even if i use a non https/ssl input, which is my primary issue. I do not have a reverse proxy, and my understanding of it was that it would be plain http everywhere besides the “connection” to through the proxy itself, which I’d prefer to have https everywhere. If I wanted to do a reverse proxy on windows, what would be the connection structure and what would be the simplest way to set it up? I am aware of these to posts, and I assume this would be the method of reverse proxy for windows

  1. Setting up secure HTTP (HTTPS) with AMP
  2. Using Caddy with AMP

Caddy is probably the best option on Windows. It’s all on the same machine so nothing leaves the system unencrypted.

Gotcha. As for the rebind not functioning properly, what are some things I can try?

Edit* I saw you edit now, I apologize. Yes, if caddy can be streamlined, that would be huge as well.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.