SMT: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Hi David,

[QUOTE=info1654;29375]Nz and i have exactly the same problem from the beguinning.

And in my opinion the SSL certs used by apache2 are not the same that the one used for the communication between SMT server and clients[/QUOTE]

since the “SMT server” is sitting behind the Apache httpd instance on your SMT machine, your statement is not right on target :wink: The SMT clients talk to the httpd, and this uses the httpd certificate.

[QUOTE=info1654;29375] I recreated certs from yast for SMT and when i am quering the files the date looks good.

openssl x509 -noout -subject -dates -in /var/lib/CAM/YaST_Default_CA/certs/01.pem
subject= /C=CA/ST=QC/L=xxxx;/O=yyyy/OU=ITS/CN=myhost/emailAddress=postmaster@postfix.com
notBefore=Aug 25 15:42:48 2015 GMT
notAfter=Aug 24 15:42:48 2016 GMT[/QUOTE]

you’re checking the file as issued by your CA. Not the copy used by your httpd.

[QUOTE=info1654;29375] If i ask my server from anywhere here is the output with the outdated date :

echo | openssl s_client -connect myhost:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Jul 13 07:51:00 2014 GMT
notAfter=Jul 13 07:51:00 2015 GMT

the apache2 cert is located here on the SMT server and there is to files :
openssl x509 -noout -subject -dates -in /etc/ssl/servercerts/servercert.pem
notBefore=Jul 13 07:51:00 2014 GMT
notAfter=Jul 13 07:51:00 2015 GMT

servercert.pem and serverkey.pem[/QUOTE]

Correct. These are the copies used by Apache2 httpd.

[QUOTE=info1654;29375] The question is , how i can replace theses 2 certificates with the YaST_Default_CA ?

I am not a guru of openssl commands but i think there is a trick to create a certificatte from another ( a CA one i think )[/QUOTE]

Nope. There are two certificates involved:

  • The CA certificate
  • The server certificate

For each of these, there’s the private key and the public certificate part.
(Server) certificates are generated by creating the private key once, and then generating “certificate signing requests”. The latter is sent to the CA, which “signs” the server certificate, generating the public certificate part (which includes the CA’s signature).

When using the YaST CA, you’re doing all these steps under YaST control, and the certificate is stored in the CA area of your file systems - your CA might be used for much more than just generating the certificates of that single server. So the part you’re missing, which is described in “Export the certificate as common server certificate, so that the http server apache uses it” from https://www.suse.com/support/kb/doc.php?id=7006024 , is exporting the renewed certificate as the “common server certificate” (means “the certificate typically to be used for the services running on this server”).

Just for the records and others hitting this thread via some search engine:

While there is a format that contains both the private key and the public certificate part in a single file (“PKCS #12”, i.e. used by Firefox), your “two files” are not created during a certificate renewal: The private key stays the same, for as long as the initial and renewed certificates are to be used. The renewal process only creates the public certificate part, including the CA signature. It’s a feature of the YaST CA scripts that it will let you also create new certificates from scratch, initially generating the private key, too. Formally, this is not part of CA processing.

Regards,
Jens