PDA

View Full Version : SMT: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed



thesunlover
09-Jun-2015, 15:04
Hi, I've got a tough SSL issue.

Issue:

smtclient# zypper update

Download (curl) error for 'https://smtserver/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

smtserver:/srv/www/htdocs# openssl x509 -in smt.crt -text | grep -A10 -B10 Validity
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
b7:b7:69:76:b4:a3:5c:ff
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, CN=YaST_Default_CA/emailAddress=
Validity
Not Before: May 12 22:31:03 2014 GMT
Not After : May 9 22:31:03 2024 GMT
Subject: C=US, CN=YaST_Default_CA/emailAddress=
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:b2:0b:b9:a5:d4:7c:69:79:0a:90:81:f0:88:1b:
84:28:cf:e7:0d:8f:cc:bf:cf:66:44:18:8a:95:e6:
7f:07:86:1f:d2:68:7f:71:03:64:7d:d0:e5:7b:e7:

Troubleshoot:

Remove old CA:

smtserver# mv /var/lib/CAM/YaST_Default_CA /tmp/YaST_Default_CA
smtserver# mv /srv/www/htdocs/smt.crt /tmp/smt.crt

Create new CA:

smtserver# yast2 ca_mgm
> 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:


Problem remains:

smtclient# /usr/lib/suseRegister/bin/clientSetup4SMT.sh --host smtserver --regcert http://smtserver/new.smt.crt
Download failed. Abort.

Please help. Thanks a lot!

nz

thesunlover
09-Jun-2015, 16:27
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):

smflood
10-Jun-2015, 10:56
On 09/06/2015 15:14, thesunlover wrote:

> Hi, I've got a tough SSL issue.
>
> Issue:
>
> smtclient# zypper update
>
> Download (curl) error for
> 'https://smtserver/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
>
> smtserver:/srv/www/htdocs# openssl x509 -in smt.crt -text | grep -A10
> -B10 Validity
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> b7:b7:69:76:b4:a3:5c:ff
> Signature Algorithm: sha1WithRSAEncryption
> Issuer: C=US, CN=YaST_Default_CA/emailAddress=
> Validity
> Not Before: May 12 22:31:03 2014 GMT
> Not After : May 9 22:31:03 2024 GMT
> Subject: C=US, CN=YaST_Default_CA/emailAddress=
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> RSA Public Key: (2048 bit)
> Modulus (2048 bit):
> 00:b2:0b:b9:a5:d4:7c:69:79:0a:90:81:f0:88:1b:
> 84:28:cf:e7:0d:8f:cc:bf:cf:66:44:18:8a:95:e6:
> 7f:07:86:1f:d2:68:7f:71:03:64:7d:d0:e5:7b:e7:
>
> Troubleshoot:
>
> Remove old CA:
>
> smtserver# mv /var/lib/CAM/YaST_Default_CA /tmp/YaST_Default_CA
> smtserver# mv /srv/www/htdocs/smt.crt /tmp/smt.crt
>
> Create new CA:
>
> smtserver# yast2 ca_mgm
>> 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:
>
>
> Problem remains:
>
> smtclient# /usr/lib/suseRegister/bin/clientSetup4SMT.sh --host smtserver
> --regcert http://smtserver/new.smt.crt
> Download failed. Abort.
>
> Please help. Thanks a lot!
>
> nz

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.
------------------------------------------------------------------------

thesunlover
11-Jun-2015, 13:44
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

Regards,
nz

jmozdzen
12-Jun-2015, 15:44
Hi nz,

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?

Regards,
Jens

thesunlover
12-Jun-2015, 21:13
Hi Jens,

How can I issue a new "server" certificate after creating the new CA certificate?

Thanks.

nz

jmozdzen
29-Jun-2015, 16:24
Hi nz,

sorry for the late reply, I had been unavailable some days on short notice.


Hi Jens,

How can I issue a new "server" certificate after creating the new CA certificate?

See this article for details: https://www.suse.com/support/kb/doc.php?id=7006024

Regards,
Jens

thesunlover
14-Jul-2015, 17:09
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


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

jmozdzen
15-Jul-2015, 11:55
Hi nz,

was there a specifc reason for specifying "--regcert", and with a non-URL value?

From https://www.suse.com/documentation/smt11/book_yep/data/smt_client_clientsetupscript.html :


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

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):

./clientSetup4SMT.sh https://smt.example.com/center/regsvc

Regards,
Jens

thesunlover
15-Jul-2015, 19:43
Thanks Jens.

I've tried

/usr/lib/suseRegister/bin/clientSetup4SMT.sh https://smtserver.mydomain.com/center/regsvc

and got exactly the same errors.

Regards,
nz

jmozdzen
16-Jul-2015, 13:24
Hi nz,

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).

Best regards,
Jens

thesunlover
17-Jul-2015, 15:58
Is this correct?

# 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.

Thanks.

nz

jmozdzen
20-Jul-2015, 09:38
Hi nz,

Is this correct?

# openssl verify -CAfile /var/lib/CAM/YaST_Default_CA/cacert.pem /etc/ssl/certs/YaST-CA.pem
/etc/ssl/certs/YaST-CA.pem: OK
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.


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.

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.

Regards,
Jens

thesunlover
21-Jul-2015, 19:21
Jens,

Is this correct?

smtserver# openssl verify -CAfile /var/lib/CAM/YaST_Default_CA/cacert.pem /etc/ssl/servercerts/servercert.pem
/etc/ssl/servercerts/servercert.pem: OK

If it's ok, what are next?

Thanks a lot!

NZ

jmozdzen
22-Jul-2015, 11:41
Hi NZ,


Jens,

Is this correct?

smtserver# openssl verify -CAfile /var/lib/CAM/YaST_Default_CA/cacert.pem /etc/ssl/servercerts/servercert.pem
/etc/ssl/servercerts/servercert.pem: OK

If /etc/ssl/servercerts/servercert.pem is the certificate used by your web server, it's a good start :)


If it's ok, what are next?

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.

Regards,
Jens

thesunlover
23-Jul-2015, 16:54
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."?

By using the following command?
/usr/lib/suseRegister/bin/clientSetup4SMT.sh https://smtserver.mydomain.com/center/regsvc

Look like we return to the original question.

Thanks.
nz

jmozdzen
23-Jul-2015, 17:32
Hi nz,


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."?

By using the following command?
/usr/lib/suseRegister/bin/clientSetup4SMT.sh https://smtserver.mydomain.com/center/regsvc

Look like we return to the original question.

from one of my an earlierer messages in this thread:

[...]
- 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).

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.

Regards,
Jens

thesunlover
31-Jul-2015, 13:08
Jens,

Thank you so much for your patience.

It's too complicated. I am afraid that I don't have more time to put on this issue. Is there a way to patch SuSE clients without using SSL?

nz

jmozdzen
31-Jul-2015, 13:56
Hi nz,

Jens,

Thank you so much for your patience.

It's too complicated.
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.


I am afraid that I don't have more time to put on this issue. Is there a way to patch SuSE clients without using SSL?

Not that I know, of, sorry.

Regards,
Jens

info1654
27-Aug-2015, 21:38
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.

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

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


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 )

From one file cert in a 2 file cert.

we re close.

david

jmozdzen
28-Aug-2015, 13:57
Hi David,

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

since the "SMT server" is sitting behind the Apache httpd instance on your SMT machine, your statement is not right on target ;) The SMT clients talk to the httpd, and this uses the httpd certificate.


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

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


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

Correct. These are the copies used by Apache2 httpd.



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 )

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").


From one file cert in a 2 file cert.

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