suse_register aborts with curl error 60 while trying to register against SMT server

This document (7002146) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 10
SUSE Linux Enterprise Desktop 10
 

Situation

While trying to register a client against a SMT server, the following error is experienced:
 
linux-client:~ # suse_register -a email=$EMAIL -a regcode-sles=$REGCODE
Execute curl command failed with '60':
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: cURL - Details on Server SSL Certificates


curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). The default
bundle is named curl-ca-bundle.crt; you can specify an alternate file
using the --cacert option.

If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).

If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

Resolution

This issue may be encountered if:
  • Time and date of server and client differ
  • The certificate got created on the server and time was adjusted afterwards so the certificate becomes invalid
  • A server certificate was configured in the vhost setup for SMT but the public part of the CA in /srv/www/htdocs/smt.crt does not match the certificate
  • The paths for the SSL directories in /etc/smt.d/vhost-ssl.conf do not match
  • The common server certificate expired

Additional Information

How to address

Cause: Time and date of server differ

Use NTP (Network Time Protocol) to synchronize the time between server and client. To accomplish this use the YaST2 NTP module to setup a NTP client.
In case there is no local NTP server available, look up the public IP of a NTP server close to your location. Please note that it might take some time for the clients to synchronize with the server. Depending on the firewall configuration, the ports to communicate with an external NTP server might need to be adjusted.

Also check time and date settings of suse_register returns the following error:

[info]  SEND DATA to URI: https://smt.office.domain/center/regsvc?command=listproducts&lang=en-US&version=1.0:
[error]  ERROR: Peer certificate cannot be authenticated with known CA certificates: (60)
[error]  (2)

Cause: Certificate was created before time was adjusted

Using the command
openssl x509 -in <certificate file> -text
it is possible to check the validity of a certificate. The important part of the output is:

linux:/srv/www/htdocs # openssl x509 -in smt.crt -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            b0:4a:85:14:d2:33:86:c8
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=DE, CN=YaST Default CA (linux)/emailAddress=postmaster@domain.site
        Validity
            Not Before: Nov 19 11:52:58 2008 GMT
            Not After : Nov 17 11:52:58 2018 GMT
        Subject: C=DE, CN=YaST Default CA (linux)/emailAddress=postmaster@domain.site
        Subject Public Key Info:

Check the Validity section in the output of the openssl command if it matches.
 
Also, use Yast | Security and Users | CA Managment to check the validity period of the server certificates, as the above command only checks the validity period of the CA.


Cause: Server certificate does not match CA

SMT stores a copy of the public part of the CA as smt.crt in /srv/www/htdocs. This copy is downloaded and used by the client to verify the SMT server.
In case a existing certificate was used to configure the Apache2 host, it might happen that the CA copy and certificate do not match.
Copy the appropriate part of the CA to /srv/www/htdocs/smt.crt and import it on the client using clientsetup4smt.sh.

Cause: Paths for SSL directories in /etc/smt.d/vhost-ssl.conf do not match

SMT stores a apache vhost-ssl.conf file in /etc/smt.d/. If the paths for the SSL certificates in this configuration file do not match the current paths (YaST-CA.pem in /etc/ssl/certs/ and servercert.pem and serverkey.pem in /etc/ssl/servercerts/ the suse_register command will compare the imported CA with a different certificate and fail.

In order to correct this either adjust the paths in /etc/smt.d/vhost-ssl-conf or restore the file from the latest smt RPM.

Cause: The common server certificate expired

Recreate the server certificate. Please see TID 000017336  - Howto recreate SMT11 CA and server certificate for details. Attention: only the server certificate has to be recreated, not the CA!

Cause: Network environment uses a proxy server

The command "./clientSetup4SMT.sh --host SMT-FQDN" returns:
 
Do you accept this certificate? [y/n] y
Client setup finished.
Start the registration now? [y/n] y
/usr/bin/suse_register -i -L /root/.suse_register.log
There are no enabled services defined.
Use 'zypper addservice' or 'zypper modifyservice' commands to add or enable services.
There are no enabled repositories defined.
Use 'zypper addrepo' or 'zypper modifyrepo' commands to add or enable repositories.
ERROR: HTTP/1.1 200 Connection established
Accept-Ranges: none
Connection: Keep-Alive

(2)
ERROR: Peer certificate cannot be authenticated with known CA certificates: (60)
(2)
ERROR: Peer certificate cannot be authenticated with known CA certificates: (60)
(2)

This issue may be experienced if the proxy is not properly configured on the system. Please use the YaST2 proxy module to configure the proxy settings and if necessary add an exclude for the SMT server.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7002146
  • Creation Date: 10-Dec-2008
  • Modified Date:30-Dec-2021
    • SUSE Linux Enterprise Desktop
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.


SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center