30.08.2024 Problem:
A client faced difficulties downloading images from their local Nexus repository using Podman. Despite several troubleshooting attempts, including adding the registry to insecure registries and adding the certificate locally, the issue persisted. The specific error encountered was related to certificate validation.
Process:
Initial Troubleshooting:
- The client added the Nexus registry to the list of insecure registries in Podman configuration.
- He also installed the certificate locally to establish a secure connection.
Expert Consultation:
- The expert identified that since Podman version 3, the use of SAN (Subject Alternative Name) in certificates for container registries is required.
- Recommended solution: Add SAN to the certificate. Alternatively, suggested downgrading Podman to version 2.
- Provided a command for troubleshooting:
GODEBUG=x509ignoreCN=0 podman login -u admin -p XXXXXXXXXXX DUMMY_NEXUS_HOST:7443
Certificate Creation and Review:
- The client created a new certificate and replaced the hostname with dummy values while sharing logs for further analysis.
- The expert reviewed the logs and identified the issue in the error message:
x509: certificate relies on legacy Common Name field, use SANs instead.
Solution:
- The expert noted that the certificate was signed with a hostname that was likely customized and not matching the actual domain name.
- Advised the client to create a new certificate using their actual domain name, ensuring that SANs were included.
Conclusion:
The client’s initial attempts to resolve the issue did not address the certificate requirements introduced in Podman v3. By following the expert’s recommendation to include SANs in the certificate and aligning it with the actual domain name, the client was able to resolve the certificate validation issue. This case highlights the importance of aligning certificate configurations with current software requirements to ensure successful integrations and operations.