If you’re standing up a private Automation Hub on Ansible Automation Platform 2.6, one of the first things you’ll want is to pull down Red Hat Certified and Validated collections from the hosted service on console.redhat.com. On paper it’s straightforward. In practice, there are a handful of gotchas that will hand you a cryptic “Failed” status with no obvious explanation. This post walks through the setup and, just as importantly, how to troubleshoot the errors you’ll almost certainly hit along the way. In this example I’m pulling some certified and validated content for configuration as code, so you’ll see references throughout.

Certified vs Verified vs Community

First, certified and verified are found via console.redhat.com only so you won’t see them on galaxy.
If you want to browse certified and verified you can find it at https://console.redhat.com/ansible/automation-hub.

– rh-certified pulls from the certified (published) content on console.redhat.com. This is where ansible.platform, ansible.controller, ansible.eda, and ansible.hub live.
– validated pulls from the validated content on console.redhat.com. This is where the redhat-cop collections like infra.aap_configuration live.
– community pulls from public Ansible Galaxy.

These do not cross-resolve. A collection whose dependencies live in a different repository will fail to sync unless you tell it not to chase those dependencies. I ran into this issue with infra as it is only in validated, so I turned off dependency syncing for validated.

Where to Configure Remotes and Repositories

In AAP 2.6 the navigation changed from older versions. You’ll find everything under Automation Content, not the old “Repo Management” label.

– Remotes (where you set URLs, tokens, and requirements): Automation Content then Remotes

– Repositories (where you kick off syncs): Automation Content then Repositories

– Sync task logs and errors: Automation Content then Task Management

Step 1: Get Your Sync URL and Offline Token

Certified and validated content both require authentication against console.redhat.com. You’ll need an offline token. RH documentation here.

1. Log into console.redhat.com as an Org Admin.
2. Navigate to the Automation Hub connect/token page.
3. Under Offline token, click Load token, then copy it.
4. Store it somewhere secure. The offline token expires after 30 days of inactivity, so if a sync that used to work suddenly starts throwing 401s, a lapsed token is the first thing to check.

Step 2: Configure the rh-certified Remote

RH docs here.

1. Go to Automation Content then Remotes.
2. Edit the rh-certified remote.
3. Confirm the Server URL points at the certified/published content endpoint:

1

https://console.redhat.com/api/automation-hub/content/published/

4. Paste your offline token into the Token field.
5. Confirm the SSO URL is populated (on the pre-seeded rh-certified remote it usually is(validated had this blank for me)):

1

https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token

6. Add a curated requirements file so you don’t sync the entire certified catalog. Syncing everything takes 30+ minutes and, worse, if any single collection in the catalog returns a bad response, the whole task fails. Scope it to what you actually need:

1
2
3
4
5
6
7
8

---
collections:
  - name: ansible.controller
  - name: ansible.platform
  - name: ansible.eda
  - name: ansible.hub
  - name: ansible.utils
  - name: ansible.posix

7. Click Save remote.

Step 3: Sync the rh-certified Repository

1. Go to Automation Content then Repositories.
2. Find rh-certified, open the actions menu, and select Sync.
3. Watch progress under Automation Content then Task Management.

Step 4: Configure the Validated Remote

Validated content lives at a different endpoint but uses the same authentication. This is where a lot of people trip up, because if you build this remote by hand or clone settings from the community remote, critical auth fields end up blank.

1. Go to Automation Content then Remotes.
2. Edit (or create) the rh-validated remote.
3. Set the Server URL to the validated content endpoint (note validated, not published):

1

https://console.redhat.com/api/automation-hub/content/validated/

4. Paste your offline token into the Token field. The validated repo requires the same token as rh-certified. The community remote does not need a token, so if you copied settings from community this field will be empty.
5. Populate the SSO URL. This is the single most common cause of a 401 on a hand-built validated remote. Without it, the hub has no endpoint to exchange your offline token for a bearer token, so it sends the request unauthenticated and gets rejected:

1

https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token

6. Leave Sync all dependencies unchecked. The dependencies of infra.aap_configuration (like ansible.platform and ansible.controller) live in the certified repo, not validated. If you leave this on, the validated sync will go hunting for them in the wrong place and fail. The UI even warns you about this inline.
7. Add a requirements file scoped to the validated content you want:

1
2
3

---
collections:
  - name: infra.aap_configuration

8. Click Save remote, then sync the rh-validated repository the same way you synced rh-certified.

Troubleshooting: Finding the Logs

When a repo shows Failed, the repository view only shows you the status flag, not the error. The actual error lives in the task record.

Go to Automation Content then Task Management, find the most recent failed sync task, and click into it. The detail view shows the error description and full traceback. You can take this message and paste it into your AI of choice and ask it “My aap2.6 private automation hub repository sync is failing with this message:”.

If the UI detail isn’t enough, pull the Pulp worker logs directly from the hub node. On a containerized AAP 2.6 install:

1
2
3

sudo -i
podman ps --format '{{.Names}}' | grep -i worker
podman logs automation-hub-worker-1 2>&1 | tail -n 200

Or via journald:

1

journalctl -u 'automation-hub-*' --since "30 min ago" --no-pager

Troubleshooting

The following are all errors I got during my setup.

404 on a Certified Endpoint for a Validated Collection

1
2

404, message='Not Found',
url='https://console.redhat.com/api/automation-hub/content/published/.../infra/aap_configuration/'

This is a wrong-repo error. You asked the rh-certified (published) remote to sync infra.aap_configuration, but that collection is validated content, not certified. The certified endpoint has no such collection, so it legitimately 404s. Fix: move infra.aap_configuration out of the rh-certified requirements file and into the validated remote.

404 on Galaxy for a Certified Dependency

1
2

404, message='Not Found',
url='https://galaxy.ansible.com/api/v3/.../ansible/platform/'

This is a dependency-resolution error. Your requirements file only listed infra.aap_configuration, but with dependency syncing enabled, Pulp tried to also pull its dependency ansible.platform from Galaxy. That collection is certified content and does not exist on public Galaxy, hence the 404. Fix: uncheck Sync all dependencies on the remote, and make sure ansible.platform comes in through your rh-certified sync instead.

401 Unauthorized on the Validated Endpoint

1
2

401, message='Unauthorized',
url='https://console.redhat.com/api/automation-hub/content/validated/api/'

This is an auth error, and it fails at the very first step before any collection is even touched. The URL is correct (validated), so the problem is purely credentials. In practice this almost always means the SSO URL field is empty on the remote. Without it, the hub can’t exchange your offline token for a bearer token, so the request goes out unauthenticated and gets a 401. Fix: populate the SSO URL field (see Step 4). Also confirm the Token field is actually populated and the offline token hasn’t expired.

503 Service Unavailable on the Gateway service-index

1
2

503 Server Error: Service Unavailable for url:
https://YOUR-HUB/api/gateway/v1/service-index/metadata/

This one is a red herring if you’re focused on content sync. Note the URL points at your own hub’s gateway, not console.redhat.com. This is the internal Resource Registry sync (which replicates users, teams, and orgs across AAP services), not a collection sync. A 503 here means the gateway’s service-index endpoint was unavailable when the task ran, usually because the gateway service was down, restarting, or coming back up in the wrong order after a platform restart. Check the gateway service health:

1
2
3
4

podman ps --format '{{.Names}} {{.Status}}' | grep -i gateway
# or, on RPM installs:
systemctl status automation-gateway
journalctl -u automation-gateway --since "30 min ago" --no-pager

Confirm the endpoint responds:

1

curl -sSk https://YOUR-HUB/api/gateway/v1/service-index/metadata/ -w '\n%{http_code}\n'

Once the gateway is healthy again, the resource-sync task clears on its next scheduled run.

Conclusion

It can be just a little fiddley at first, but it’s honestly pretty straight forward once you step through it once. Keep in mind you will have to regularly update your requirements files, though you can create multiple remotes and repos all pointing to the same place, but with different requirements.

Good luck and happy automating!