AAP 2.5 Installation with gateway URL different from hostname

Hi all,
I’m stuck in the installation process for AAP 2.5.
I’d like to use a URL for the gateway which is different from the hostname.
FQDN: test.corp.name.com
URL: aap.newname.de

There are custom certificates defined for the URL

I am using the URL as hostname in the inventory.

Now I get the following error:

TASK [ansible.containerized_installer.automationgateway : Update automation platform gateway service clusters] ***************************************************************
task path: /home/ansible/install_aap2513/collections/ansible_collections/ansible/containerized_installer/roles/automationgateway/tasks/postinstall.yml:35
failed: [aap.newname.de] (item={'name': 'gateway', 'service_type': 'gateway'}) => {"ansible_loop_var": "item", "changed": false, "item": {"name": "gateway", "service_type": "gateway"}, "msg": "c{'service_type': ['Incorrect type. Expected pk value, received str.']}"}
failed: [aap.newname.de] (item={'name': 'controller', 'service_type': 'controller'}) => {"ansible_loop_var": "item", "changed": false, "item": {"name": "controller", "service_type": "controller"}, "msg": "c{'service_type': ['Incorrect type. Expected pk value, received str.']}"}
failed: [aap.newname.de] (item={'name': 'hub', 'service_type': 'hub'}) => {"ansible_loop_var": "item", "changed": false, "item": {"name": "hub", "service_type": "hub"}, "msg": "c{'service_type': ['Incorrect type. Expected pk value, received str.']}"}
failed: [aap.newname.de] (item={'name': 'eda', 'service_type': 'eda'}) => {"ansible_loop_var": "item", "changed": false, "item": {"name": "eda", "service_type": "eda"}, "msg": "c{'service_type': ['Incorrect type. Expected pk value, received str.']}"}

I had an issue with a task regarding the certification verification when the gateway starts during the process. But could solve it by adding the custom ca certs (root and intermediate) to the trust store which is located in the aap directory aap/tls/extracted/pem/tls-ca-bundle.pem.

Don’t know if the earlier issue has an impact, but think it might be important, that I did a manual change inside the aap installation.

Hope someone can help?

Best regards,
Rainer

Ok, some updates from my side.

The solution I found to overcome the failing certification check when the automation-gateway ist started, is not lasting.
The installation seems to fail to add the custom certifications to the locally used pki trust files in aap/tls/… or ~/.local/share/…

I also tried to use release 2.5.15 instead of 2.5.13, no change.

Still open for any suggestions and questions.

Cheers,
Rainer

Hi Rainer,

I unfortunately have no solution but would like to point out that I’m having the same problem. I had a fully functioning AAP 2.5.13 containerized installation on RHEL 9 and tried to upgrade to 2.5.15 when I hit this problem. I took a vSphere snapshot before the upgrade which I reverted to, but now 2.5.13 is acting up and when I try to install that version again, I get the same error you’re getting.

I tried completely starting from scratch with the installation after a full uninstallation, including deleting the entire “aap”, “.config”, “.local”, etc. folders on all servers, to no avail. Hopefully someone else can be more helpful because I’m stuck. (Luckily, I still have an AAP 2.4 installation that we haven’t fully migrated off of yet).

Thank you,
Robert

Hi Robert,
thanks for letting me know, that I am not the only one.
Today I changed the settings and used the same TLS certificate for all the components.
I mean controller, gateway, hub, eda, postgres,…
Still the same error.

It seems that the customer CA certifications, actually the intermediate specific to us, is not rolled out on those places where it’s needed.

Is this approach to use own certificates unusual?

Cheers,
Rainer

Rainer,

It’s good to know I’m not alone, too! I don’t think it’s unusual at all, that’s how I had it working for the past 2 months or so. I used InCommon to create my cert with a DNS failover set between my 2 gateways and it was working this whole time. It’s only when I tried to upgrade, then undo the upgrade (that failed) and now I can’t get it up and running again. Even reverting to snapshot didn’t work. I have no idea what I did to break it! I’m talking with my database team now to see if we can wipe the database and start fresh (with a backup of the database in case wiping doesn’t help).

Robert

Actually, my database team is noticing an interesting SQL error:

2025-06-05 15:01:08.442 CDT [2160740] ERROR: column aap_gateway_api_servicecluster.service_type does not exist at character 278

He said when he changed that column to “aap_gateway_api_servicecluster.service_type_id”, the SQL runs successfully. So could it be just a bug in the installation? I’m going to poke at the containerized installation and see if I can find that.

Robert

Hey Robert,
the same for me. I tried and tried.

Today I found the time, to dig really deep and found the issue, why my installation fails.

There where 2 changes I made.
The first one, I added my custom tls certification to all the components, which might not be required.
And the second change I made was the correction of a typo in a variable custom_ca_cert.
It was so hidden, that I couldn’t see it.

So finally, it was again a fault by the user, and I wondered what I could do wrong.

If you need more information, I’m happy to share.

Cheers,
Rainer

Good luck!
I think it’ll just take time.