SSL Certificate verification fails fro SMT server

SUSE Linux Enterprise Server SLES Updates
1

Hello,
I have an environment with about a dozen or so SLES 12 SP1 and SP2 servers that are all getting patches off a local SMT server. All of the servers have been working fine, but after updating one SP1 server, upon reboot, it no longer will trust the certificate used on the SMT server. Any time I try and patch it or use SUSEConnect I get:

SSL verification failed: self signed certificate in certificate chain
Certificate issuer: /C=US/CN=YaST Default CA (sles-smt3)/emailAddress=postmaster@sles-smt3
Certificate subject: /C=US/CN=YaST Default CA (sles-smt3)/emailAddress=postmaster@sles-smt3
SUSEConnect error: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed

I took the cert and put in /etc/pki/trust/anchors and ran update-ca-certificates, but it still errors out. I also checked /var/lib/ca-certificates/ca-bundle.pem and the certificate is indeed in that file.

All the other servers work just fine, it’s just this single SLES 12 SP1 server refuses to trust it and I am baffled as to why.

Any ideas where else to look or how to fix this?

Thanks.

Matt

2

Hi
Is the date/time correct on the server that’s playing up? Else have a look at https://www.suse.com/support/kb/doc/?id=7004748.

3

Well, the time is correct on the servers. But I did look at registrations on the SMT server. I think this is the problem server:

SCC_275061e5d1e44175b253e9e3848c7429 | 192.168.0.245 | 2017-07-20 14:00:55 | | SLES 12.1 x86_64

If you look at that time, it is in the future! I’m not sure how the heck that happened. So I tried to delete it, I got an error:

Successfully delete registration locally : SCC_275061e5d1e44175b253e9e3848c7429
Failed to delete registration for id malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before “(end of string)”) at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCAPI.pm line 510.

I tried to then register the problem server, but I still get the same error about the cert.

Matt

4

Hi
So time on the SMT server is all ok as well?

SMT server is all up to date with patches etc?

zypper ref
zypper lu
zypper lu -t patch

Did you use the -g option to delete the registration? Maybe some additional info in /var/log/smt/smt-report.log

5

Yes, the SMT server is all up to date, I checked that. Time is fine, I checked it.

I also just installed a new SLES 12 SP2 server pointing at that registration server and it worked just fine, no issues with the cert.

I’m truly baffled as to why I cannot get this one server to trust the cert.

Matt

6

Hi
What does it show for;

smt-list-registrations

Are all the registration codes similar? I wonder if the UNIQUE_ID is incorrect so it doesn’t delete? Also did you check the logs for any other clues?

Not sure if anything relevant here;
SMT Master TID: https://www.suse.com/support/kb/doc/?id=7005002

7

Well it is gone from the list of registrations now. When I did the smt-delete-registration, even though it produced an error, it wiped it out.

If I look at the /etc/zypp/credentials.d dir, I see the file for the SMT server, but that username value is gone from the list of registrations now. I wonder if I should clear out the credential files maybe?

Which log may lend a clue?

I may resort to just bringing this box up to SP2 using the ISO and then see if I can get it to re-register maybe.

Matt

8

I think I made an interesting discovery. I was using openssl to test connectivity to the SMT server, and I noticed this when I launched the command:

WARNING: can’t open config file: /FIPS/1.0.2k/Linux_x86_64/ssl/openssl.cnf

This server has NetIQ eDirectory 9 on it. I’m wondering if eDir messed with the SSL configuration on the server? I’m wondering now if that is the whole problem, it cannot find openssl.cnf and therefore cannot find the trusted root file maybe???

Matt

9

Hi
There should be /var/log/smt/smt-report.log ?

What about the system BIOS date and time? Are you setting
system/hardware time to UTC? BIOS Battery failing(?)

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.73-18.17-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

10

Hi
I wouldn’t have thought so… I think you would need to ask in the
eDirectory forum about that;
https://forums.novell.com/forumdisplay.php/1322-eDirectory

What openssl command where you using to test?

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.73-18.17-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

11

That was indeed the issue.

So I created that dir structure:

mkdir -p /FIPS/1.0.2k/Linux_x86_64/ssl

And then made a symbolic link to the conf file:

ln -s /etc/ssl/openssl.cnf /FIPS/1.0.2k/Linux_x86_64/ssl/openssl.cnf

I also had to copy the CA bundle there:

cp /etc/ssl/ca-bundle.pem /FIPS/1.0.2k/Linux_x86_64/ssl/

and I added a link to the certs dir too:

ln -s /etc/ssl/certs /FIPS/1.0.2k/Linux_x86_64/ssl/certs

And presto! SUSEConnect and Zypper all started working again, no complaints about the certs. I migrated the server to SP2 no problem.

Oh, and I was just doing this for my testing:

openssl s_client -connect :443

Matt

12

Hi
Sounds like a bug report for eDirectory may be needed… SP2 is
running 1.0.2j

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.73-18.17-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!