The development team asks a Linux administrator to help diagnose a connectivity issue that is...

The correct answer is A. Verify the remote certificate is trustworthy, and add it to the local trusted certificates repository because the error clearly indicates that the system does not recognize the certificate authority (CA) that issued the server’s SSL/TLS certificate. This is a trust issue, not necessarily a problem with the certificate itself.

When wget reports that the certificate “is not trusted” and “does not have a known issuer,” it typically means the CA certificate is missing from the local trust store. The proper and secure resolution is to first validate that the remote certificate is legitimate (for example, confirming it with the issuing authority or organization). Once verified, the administrator should add the CA certificate to the system’s trusted certificate store (e.g., /etc/pki/ca-trust/ or /usr/local/share/ca-certificates/ depending on the distribution) and update the trust database.

Option B is incorrect because using a self-signed certificate introduces additional trust issues and is not appropriate for production environments unless properly managed.

Option C is incorrect because the error message does not indicate that the certificate is expired, only that the issuer is unknown.

Option D is incorrect because using --no-check-certificate bypasses SSL verification entirely, which creates a significant security vulnerability and violates best practices.

From a Linux+ security perspective, maintaining proper certificate validation is essential for secure communications. Administrators must ensure that trusted CAs are properly configured rather than bypassing verification mechanisms.