Renewing expired custom SSL certificates on Capsule server fails when executing the 'satellite-installer' step

Solution Verified - Updated 29 May 2026

Environment

Red Hat Satellite 6.x
Red Hat Capsule 6.x

Issue

While renewing an expired custom SSL certificate on a Capsule Server following 15.3. Renewing a custom SSL certificate on Capsule Server, running the satellite-installer command generated by the capsule-certs-generate command fails with the following error:

2026-04-23 11:34:01 [ERROR ] [configure] /Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[capsule.example.com]: Failed to call refresh: Error making PUT request to https://satellite.example.com/api/v2/smart_proxies/3/refresh: Response: 500 Internal Server Error: Check /var/log/foreman/production.log on satellite.example.com for detailed information
2026-04-23 11:34:01 [ERROR ] [configure] /Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[capsule.example.com]: Error making PUT request to https://satellite.example.com/api/v2/smart_proxies/3/refresh: Response: 500 Internal Server Error: Check /var/log/foreman/production.log on satellite.example.com for detailed information
2026-04-23 11:34:03 [NOTICE] [configure] System configuration has finished.

Error 1: Puppet Foreman_smartproxy resource 'capsule.example.com' failed. Logs:
  /Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[capsule.example.com]
    Adding autorequire relationship with Anchor[foreman::providers::oauth]
    Starting to evaluate the resource (1122 of 1135)
    Failed to call refresh: Error making PUT request to https://satellite.example.com/api/v2/smart_proxies/3/refresh: Response: 500 Internal Server Error: Check /var/log/foreman/production.log on satellite.example.com for detailed information
    Error making PUT request to https://satellite.example.com/api/v2/smart_proxies/3/refresh: Response: 500 Internal Server Error: Check /var/log/foreman/production.log on satellite.example.com for detailed information
    Evaluated in 0.26 seconds
  Foreman_smartproxy[capsule.example.com](provider=rest_v3)
    Making get request to https://satellite.example.com/api/v2/smart_proxies?search=name%3D%22capsule.example.com%22
    Received response 200 from request to https://satellite.example.com/api/v2/smart_proxies?search=name%3D%22capsule.example.com%22
    Making put request to https://satellite.example.com/api/v2/smart_proxies/3/refresh
    Received response 500 from request to https://satellite.example.com/api/v2/smart_proxies/3/refresh

1 error was detected during installation.
Please address the errors and re-run the installer to ensure the system is properly configured.
Failing to do so is likely to result in broken functionality.

The full log is at /var/log/foreman-installer/capsule.log

Resolution

Follow the steps in the Diagnostic Steps section of this solution article to verify that the reported issue matches with the one documented here. Proceed with the next steps of the resolution only if you get similar outcomes from the diagnostic steps.
Created a workspace to create a global CA bundle that contains the full path of trust for both the Satellite and Capsule servers:

# mkdir -p /root/satellite_trust_update
# cd /root/satellite_trust_update

Combine the CA bundle file for the Satellite server with the CA bundle file for the Capsule server.
The 2 CA bundle files are included with the signed certificates of the Satellite and Capsule servers, which are provided by the certificate authority (CA) in response to the Certificate Signing Request (CSR).
To combine the 2 files, use the following commands:

# cat /root/satellite_cert/satellite.example.com_ca_bundle.pem > satellite_global_ca_bundle.pem
# cat /root/capsule_cert/capsule.example.com_ca_bundle.pem >> satellite_global_ca_bundle.pem

Apply the combined CA bundle to the Satellite server. This tells the Satellite's web server and services to trust any certificate signed by either of the intermediate CAs which signed the Satellite and Capsule custom SSL certificates.
To do so, run the following command on the Satellite server:

# satellite-installer --scenario satellite \
--certs-server-ca-cert "/root/satellite_trust_update/satellite_global_ca_bundle.pem" \
--certs-update-server-ca

Rerun the failed satellite-installer command on the Capsule server to configure it with the custom SSL certificates.

For more KB articles/solutions related to Red Hat Satellite 6.x SSL Certificates Issues, please refer to the Consolidated Troubleshooting Article for Red Hat Satellite 6.x SSL Certificates Issues

Root Cause

The Satellite's and Capsule's custom SSL certificates are signed by 2 different intermediate CAs within the same CA hierarchy.

Diagnostic Steps

On the Satellite server, look for the following error in /var/log/foreman/production.log:

  # grep -C 5 "api/v2/smart_proxies/3/refresh" /var/log/foreman/production.log

  2026-04-23T11:32:47 [I|app|385b0dc7] Started PUT "/api/v2/smart_proxies/3/refresh" for 192.168.xx.xx at 2026-04-23 11:32:47 +0000
  2026-04-23T11:32:47 [I|app|385b0dc7] Processing by Api::V2::SmartProxiesController#refresh as JSON
  2026-04-23T11:32:47 [I|app|385b0dc7]   Parameters: {"apiv"=>"v2", "id"=>"3", "smart_proxy"=>{}}
  2026-04-23T11:32:47 [I|app|385b0dc7] Authorized user foreman_api_admin(API Admin)
  2026-04-23T11:32:47 [W|app|385b0dc7] Action failed
  2026-04-23T11:32:47 [I|app|385b0dc7] Backtrace for 'Action failed' error (ProxyAPI::ProxyException): ERF12-9411 [ProxyAPI::ProxyException]: Unable to fetch public key ([RestClient::SSLCertificateNotVerified]: SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate)) for Capsule https://capsule.example.com:9090/ssh

This indicates that the Satellite server does not yet trust the new certificate presented by the Capsule, or there is a mismatch in the OAuth credentials/SSL trust chain between the two.

Confirm that the Satellite's and the Capsule's custom SSL certificates are signed by 2 different intermediate CAs:

# openssl storeutl -noout -text -certs /root/satellite_cert/satellite.example.com.crt | grep Issuer
        Issuer: C=XX, DC=com, DC=example, ST=State, L=City, O=General Corp, OU=IT, OU=Security, CN=Intermediate CA 1

and

# openssl storeutl -noout -text -certs /root/capsule_cert/capsule.example.com.crt | grep Issuer
        Issuer: C=XX, DC=com, DC=example, ST=State, L=City, O=General Corp, OU=IT, OU=Security, CN=Intermediate CA 2

In this instance:
- The Satellite's custom SSL certificate is signed by Intermediate CA 1.
- The Capsule's custom SSL certificate is signed by Intermediate CA 2.

Cross-check the trusted CA list from the CA bundle of Satellite server:

  # awk -v cmd='openssl x509 -noout -subject' '    /BEGIN/{close(cmd)};{print | cmd}' < satellite.example.com_ca_bundle.pem  2>&1 | sed 's/subject=//'

  C=XX, DC=com, DC=example, ST=State, L=City, O=General Corp, OU=IT, OU=Security, CN=Intermediate CA 1
  C=XX, ST=State, L=City, O=General Corp, OU=IT, OU=Security, CN=Policy CA
  L=City, ST=State, C=XX, OU=IT, OU=Security, O=General Corp, CN=ROOT CA

with the trusted CA list from the CA bundle of the Capsule server:

  # awk -v cmd='openssl x509 -noout -subject' '    /BEGIN/{close(cmd)};{print | cmd}' <  capsule.example.com_ca_bundle.pem  2>&1 | sed 's/subject=//'

  C=XX, DC=com, DC=example, ST=State, L=City, O=General Corp, OU=IT, OU=Security, CN=Intermediate CA 2
  C=XX, ST=State, L=City, O=General Corp, OU=IT, OU=Security, CN=Policy CA
  L=City, ST=State, C=XX, OU=IT, OU=Security, O=General Corp, CN=ROOT CA

In this instance the SSL certificates of the 2 intermediate CAs Intermediate CA 1 and Intermediate CA 2 are signed by the same upstream CA Policy CA, whose certificate is in turn signed by the root CA ROOT CA.

Check the trust store on the Satellite server using the following command:

# trust list | grep 'Intermediate CA'
    label: Intermediate CA 1

In this instance, Intermediate CA 2 (the intermediate CA which signed the Capsule's custom SSL certificates) is missing from the trust list on the Satellite server.

SBR

SysMgmt

Product(s)

Red Hat Satellite

Components

Category

Troubleshoot

Tags

capsule
ssl

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.