Create Root CA > CA Name = YaST_Default_CA > Common Name: YaST_Default_CA > … > Next > Password = 123456 > Next > Create
Enter CA > Advanced > Export to File > Only the Certificate in PEM Format > File Name = /srv/www/new.smt.crt > Ok > Ok > Finish
smtserver# openssl x509 -in /srv/www/new.smt.crt -text | grep -A10 -B10 Validity
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
ff:23:46:41:93:d4:6c:83
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Ok, L=Ok, O=Ok, OU=Ok, CN=YaST_Default_CA/emailAddress=
Validity
Not Before: Jun 8 19:15:54 2015 GMT
Not After : Jun 5 19:15:54 2025 GMT
Subject: C=US, ST=Ok, L=Ok, O=Ok, OU=Ok, CN=YaST_Default_CA/emailAddress=
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:b7:1e:04:68:79:57:1b:ad:66:4a:09:00:e6:48:
37:b8:f0:e9:2e:f9:c2:65:2b:85:b4:ee:3f:66:18:
a0:f0:ad:96:15:7d:e9:49:37:31:8a:fd:0a:ab:b1:
The SMT client can not be registered to the SMT server by using the new SSL key:
smtclient# /usr/lib/suseRegister/bin/clientSetup4SMT.sh --host smtserver --regcert http://smtserver/new.smt.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
ff:23:46:41:93:d4:6c:83
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Ok, L=Ok, O=Ok, OU=Ok, CN=YaST_Default_CA/emailAddress=
Validity
Not Before: Jun 8 19:15:54 2015 GMT
Not After : Jun 5 19:15:54 2025 GMT
Subject: C=US, ST=Ok, L=Ok, O=Ok, OU=Ok, CN=YaST_Default_CA/emailAddress=
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
…
…
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
Netscape Comment:
YaST Generated CA Certificate
Netscape Cert Type:
SSL CA, S/MIME CA
X509v3 Key Usage:
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
62:F2:2A:FD:26:61:77:21:8B:5A:DB:93:8B:75:C6:89:BD:DA:DC:23
X509v3 Authority Key Identifier:
keyid:62:F2:2A:FD:26:61:77:21:8B:5A:DB:93:8B:75:C6:89:BD:DA:DC:23
DirName:/C=US/ST=Ok/L=Ok/O=Ok/OU=Ok/CN=YaST_Default_CA/emailAddress=
serial:FF:23:46:41:93:D4:6C:83
X509v3 Subject Alternative Name:
email:
X509v3 Issuer Alternative Name:
email:
Signature Algorithm: sha1WithRSAEncryption
......................................................
......................................................
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
Refreshing service ‘SMT-http_smtserver_corp_com’.
All services have been refreshed.
Download (curl) error for ‘https://smtserver.com/repo/full/$RCE/SLES11-SP3-VMware-Pool/sle-11-x86_64/repodata/repomd.xml’:
Error code: Unrecognized error
Error message: SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Abort, retry, ignore? [a/r/i/? shows all options] (a):
Create Root CA > CA Name = YaST_Default_CA > Common Name:[/color]
YaST_Default_CA > … > Next > Password = 123456 > Next > Create[color=green]
Enter CA > Advanced > Export to File > Only the Certificate in PEM[/color]
Format > File Name = /srv/www/new.smt.crt > Ok > Ok > Finish
smtserver# openssl x509 -in /srv/www/new.smt.crt -text | grep -A10 -B10
Validity
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
ff:23:46:41:93:d4:6c:83
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Ok, L=Ok, O=Ok, OU=Ok,
CN=YaST_Default_CA/emailAddress=
Validity
Not Before: Jun 8 19:15:54 2015 GMT
Not After : Jun 5 19:15:54 2025 GMT
Subject: C=US, ST=Ok, L=Ok, O=Ok, OU=Ok,
CN=YaST_Default_CA/emailAddress=
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:b7:1e:04:68:79:57:1b:ad:66:4a:09:00:e6:48:
37:b8:f0:e9:2e:f9:c2:65:2b:85:b4:ee:3f:66:18:
a0:f0:ad:96:15:7d:e9:49:37:31:8a:fd:0a:ab:b1:
Which version of SUSE Linux Enterprise Server (SLES) are you using? From
your output I’m guessing something earlier than SLES12. Please post the
output from “cat /etc/*release”.
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
Simon, Thank you for your reply. Here is the info:
cat /etc/*release
LSB_VERSION=“core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64”
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3
what happened to the SMT server’s certificate after the recreation of the CA? Did you issue a new server certificate after creating the new CA certificate, and restart the web server after exporting the certificate to the server?
Thanks Jens for the info and sorry about the delayed reply.
I’ve followed the instructions of the documentation to create CA and server certificate, but still failed to import the newly created CA to the SMT clients. Here are the output:
smtclient# /usr/lib/suseRegister/bin/clientSetup4SMT.sh --host smtserver.ourdomain.com --regcert smtserver.ourdomain.com
…
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
Refreshing service ‘SMT-http_smtserver_ourdomain_com’.
All services have been refreshed.
Download (curl) error for ‘https://smtserver.ourdomain.com/repo/full/$RCE/SLES11-SP3-VMware-Pool/sle-11-x86_64/repodata/repomd.xml’:
Error code: Unrecognized error
Error message: SSL peer certificate or SSH remote key was not OK
Abort, retry, ignore? [a/r/i/? shows all options] (a):
It’s tough. Please help. Thank you!
nz
[QUOTE=jmozdzen;28569]Hi nz,
sorry for the late reply, I had been unavailable some days on short notice.
See this article for details: https://www.suse.com/support/kb/doc.php?id=7006024
Regards,
Jens[/QUOTE]
[QUOTE]
In the second case, the script uses the --host option followed by the hostname of the SMT server, and --regcert followed by the URL of the SSL certificate; for example:
./clientSetup4SMT.sh --host smt.example.com \
–regcert http://smt.example.com/certs/smt.crt[/QUOTE]
But it should have been fully sufficient to download the CA certificate and thus implicitly trust the CA-generated server certificate (i.e. the one you’ll issue once the current server certificate expires):
my last invocation of that scripts is months ago and I’m offsite for a few days, so I cannot look up the details, so here’s just a general guideline:
either analyze the script (or call it via “bash -x” for debugging output) to see where the CA certificate is downloaded to
use “openssl x509 -noout -text -in CaCertFilename.pem” and have a look at the details of the certificate: Is that the new CA cert (should be obvious, i.e. via the “Validity Not Before” value)
if it’s not the new CA cert, check why your SMT server does not have that file at the expected location and fix that.
if that’s a proper certificate, determine the certificate file used by the SMT web server and verify that it is valid via “openssl verify -CAfile CaCertFilename.pem ServerCertFilename.pem”
Or you could also try to connect to the URL via browser… after you have imported the CA certificate there. Maybe the error message there is more use-friendly than doing things by hand.
If you can successfully connect via browser, the last error cause could be with curl - you’d check the ~root/.curlrc file for any obvious configuration problems and invoke the curl command manually to see why it doesn’t work as expected. A typical error cause would be a non-accessible CA certificate (on the client system), assuming the SMT-side setup is correct (proper certs in proper locations).
# openssl verify -CAfile /var/lib/CAM/YaST_Default_CA/cacert.pem /etc/ssl/certs/YaST-CA.pem
/etc/ssl/certs/YaST-CA.pem: OK
Do we need to get updated SuSE licenses from Novell in order to make SSL work? The current SuSE servers were built on VMware 2 years ago. Novell provided licenses for VMs at that time, but stopped doing it now.
# openssl verify -CAfile /var/lib/CAM/YaST_Default_CA/cacert.pem /etc/ssl/certs/YaST-CA.pem
/etc/ssl/certs/YaST-CA.pem: OK[/QUOTE]
that’s not what I was thinking of: You were verifying your (self-signed) CA certificate (from file YaST-CA.pem) by checking it’s signature, expected to match the CA cert from file cacert.pem. From what I can tell, these two files should be identical, as you should have only a single CA.
There’s the server certificate as well - the one that’s used by your SMT server and goes to smtserver:/etc/ssl/servercerts/servercert.pem by default (i.e. when exporting the server cert from YaST CA, to be the default server certificate). That’s the one to verify against the CA.
The basic idea behind this all is as follows:
The client gets a copy of the (rather long-living) CA certificate installed, i.e. during SMT client setup.
The SMT server presents its server certificate to the client on each connect, the client then uses the CA certificate to verify that it’s actually a valid cert signed by your CA
So you need to make sure two things:
the server needs to use a server certificate issued by your CA
** the server cert is (by default) generated in the CA on the SMT server
** the server cert is signed by the CA certificate
** the server cert is exported as “server default certificate” on the SMT server
** the SMT Apache httpd configuration references the exported cert(+key), to use it for HTTPS connections
the client needs to use the CA certificate to successfully verify the server cert during each connect
** on the SMT server, (a copy of) the CA cert is made available in a way it can be downloaded via HTTPS
** the CA certificate is installed on the client i.e. via SMT client install
As you have reinstalled the complete CA, you’ll need to make sure that the server offers the proper new CA and server certificates to the client and that the client uses the proper CA certificate to verify the certificate presented by the server during HTTPS session establishment.
While I cannot say much about “SLES for VMware” licensing issues, you’ll need no special/upgraded license for SSL encryption. And while I see some politicians fighting against strong encryption, I did not notice any reports on such bans being in effect, yet.
If /etc/ssl/servercerts/servercert.pem is the certificate used by your web server, it’s a good start
You need to follow the data flow:
As pointed out above, you need to check if the CA certificate downloaded and used by the smt client is actually the same one as the CA cert you used above to verify the server cert. This may well be your culprit here, at least that’s my best guess (that the copy of the CA certificate file, made available for download by the installer script, wasn’t updated)
Then I’d recommend to manually try the curl download you referenced in your initial message, to verify that curl does have access to that CA cert when verifying the server server upon HTTPS session establishment.
Once that works, the SMT client should be operational.
How can I “…check if the CA certificate downloaded and used by the smt client is actually the same one as the CA cert you used above to verify the server cert.”?
[QUOTE=thesunlover;28847]How can I “…check if the CA certificate downloaded and used by the smt client is actually the same one as the CA cert you used above to verify the server cert.”?
Look like we return to the original question.[/QUOTE]
from one of my an earlierer messages in this thread:
[QUOTE=jmozdzen;28752][…]
either analyze the script (or call it via “bash -x” for debugging output) to see where the CA certificate is downloaded to
use “openssl x509 -noout -text -in CaCertFilename.pem” and have a look at the details of the certificate: Is that the new CA cert (should be obvious, i.e. via the “Validity Not Before” value)
if it’s not the new CA cert, check why your SMT server does not have that file at the expected location and fix that.
if that’s a proper certificate, determine the certificate file used by the SMT web server and verify that it is valid via “openssl verify -CAfile CaCertFilename.pem ServerCertFilename.pem”
Or you could also try to connect to the URL via browser… after you have imported the CA certificate there. Maybe the error message there is more use-friendly than doing things by hand.
If you can successfully connect via browser, the last error cause could be with curl - you’d check the ~root/.curlrc file for any obvious configuration problems and invoke the curl command manually to see why it doesn’t work as expected. A typical error cause would be a non-accessible CA certificate (on the client system), assuming the SMT-side setup is correct (proper certs in proper locations).[/QUOTE]
So you find out where the CA cert ends up on the client machine and verify it’s really the new one. You could use any browser to connect to the SMT server and check that it actually presents the new server cert (verify the certificate subject and the validity dates, which should already indicate enough) and if it’s the same as the one you verified earlier against the CA cert, on the SMT server, then this part would be covered.
You could also use “openssl s_client” from the client machine, but would need to look up (“man s_client”) how to specify the SMT server URL and the CA certificate file that the SMT client installer downloaded to your client machine.
It’s too complicated.[/QUOTE]
from my point of view, it looks fairly simple, but otoh, I’m used to working with certificates for years.
you have a CA that identifies by the CA certificate
the CA creates a server certificate and “signs” the server certificate
the SMT server uses that server certificate, and makes a copy of the CA certificate available for download
the SMT client installer downloads the CA certificate via a http request, from the SMT server, and makes it available to the SSL routines on the client
the SMT client during its operations verifies the server certificate (exchanged as part of the SSL request) by checking its CA signature. For this it needs access to the downloaded copy of the CA certificate.
To debug, you just hunt down the certificates used, client side, and check that they are the proper ones. Once you know which certificate is wrong you can track down why.
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
I recreated certs from yast for SMT and when i am quering the files the date looks good.
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
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 )
