Problems registering and updating

SUSE Product Topics SLES Updates
1

We have bought 2 keys for 2 servers to try and register them and get updates.

One of the servers is SLES 11SP3. When I try the command:
suse_register -a regcode-sles=XXXXXXXXXXXX -a email=XXXXXXXXX -L /root/.suse_register.log

I get:
Problem retrieving the repository index file for service ‘nu_novell_com’:
Download (curl) error for ‘https://nu.novell.com/repo/repoindex.xml?cookies=0&credentials=NCCcredentials’:
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

I tried disabling and enabling repositories and I also removed the CA cert and recreated it following https://www.novell.com/support/kb/doc.php?id=7006024 but to no avail. In the knowledgebase document I got to when I had to restart SMT using “rcsmt restart” which the system said does not exist.

The second server is SLES 11SP2.

When running the command: “suse_register -a regcode-sles=XXXXXXXXXXXX -a email=XXXXXXXXX -L /root/.suse_register.log” I do actually get: Registration finished successfully.

But then I went and checked and there are no repositories. Not even 1. So I tried adding some from http://scc.suse.com/ where I found them listed with the subscriptions, but every one I try I get:
Permission to access ‘https://updates.suse.com…’ denied.

Can anyone please help me resolve these issues?

If it helps on the SLES11 SP3 (which has the SSL error):
Output of: rpm -qa | grep ssl

openssl-0.9.8j-0.70.1 libopenssl0_9_8-32bit-0.9.8j-0.70.1 openssl-certs-1.97-0.3.1 libopenssl0_9_8-0.9.8j-0.70.1

Output of: openssl verify -CAfile /var/lib/CAM/YaST_Default_CA/cacert.pem /etc/ssl/certs/YaST-CA.pem

/etc/ssl/certs/YaST-CA.pem: OK

Output of: openssl x509 -in /var/lib/CAM/YaST_Default_CA/cacert.pem -text | grep -A10 -B10 Validity

Certificate: Data: Version: 3 (0x2) Serial Number: cc:90:37:cc:ad:3b:b7:b8 Signature Algorithm: sha1WithRSAEncryption Issuer: C=MT, O=RS2 Software, CN=YaST_Default_CA/emailAddress=it@rs2.com Validity Not Before: Jul 15 11:41:29 2015 GMT Not After : Jul 12 11:41:29 2025 GMT Subject: C=MT, O=RS2 Software, CN=YaST_Default_CA/emailAddress=it@rs2.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:d6:10:cd:6d:c1:6c:59:b5:29:5e:b9:0e:d2:79: 8f:ef:84:67:a6:26:0c:bb:c8:e8:42:a0:73:53:ee: 71:ac:7a:75:37:d1:6e:fe:4c:c7:00:37:73:1f:da:

On the other server the SLES SP2 which registers but I cannot add repos:

Output of: rpm -qa | grep ssl

libopenssl0_9_8-0.9.8j-0.26.1 openssl-0.9.8j-0.26.1 openssl-certs-0.9.8h-27.3.1 libopenssl0_9_8-32bit-0.9.8j-0.26.1

Output of: openssl verify -CAfile /var/lib/CAM/YaST_Default_CA/cacert.pem /etc/ssl/certs/YaST-CA.pem

/etc/ssl/certs/YaST-CA.pem: OK

Output of: openssl x509 -in /var/lib/CAM/YaST_Default_CA/cacert.pem -text | grep -A10 -B10 Validity

Certificate: Data: Version: 3 (0x2) Serial Number: d8:52:6b:66:0a:c3:02:ae Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, CN=YaST Default CA (PCI-WEBSRV)/emailAddress=postmaster@rs2.com Validity Not Before: Mar 24 17:48:46 2015 GMT Not After : Mar 21 17:48:46 2025 GMT Subject: C=GB, CN=YaST Default CA (PCI-WEBSRV)/emailAddress=postmaster@rs2.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:c9:49:1d:7e:62:0a:c8:ef:a6:b2:a1:df:ff:1a: 22:5b:df:ef:e5:d6:76:78:3e:bc:96:be:e5:97:8e: dd:a2:2c:c2:16:8f:28:d1:4c:65:7b:96:b6:21:8b:

Any help would be appreciated. Thanks.

2

Hi rs2software,

as those are two new keys, are you able to open service requests in SCC, based on complimentary installation support?

From your description, it seems you have a local SMT server - and to me it looks like your mixing two potential trouble causes:

[QUOTE]Problem retrieving the repository index file for service ‘nu_novell_com’:
Download (curl) error for 'https://nu.novell.com/repo/repoindex.xml?cookies=0&credentials=NCCcredentials ':
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[/QUOTE]

Unless you tried some voodoo to make your SMT server reachable via nu.novell.com, the SSL problem seems to occur when contacting Novell’s site. So anything you do with your own CA won’t apply: Novell’s site certificate is signed by DigiCert :wink:

Have you tried using curl manually to retrieve that URL? It won’t work (as the parameters don’t match the actual values), but should at least get past the SSL session initiation step. If it doesn’t, which I hope for, you’d have a test case to find out why the certificate verification fails.

Were the machines already configured to act as SMT clients, before running suse_register?
Is there any HTTPS proxy involved?

Regards,
Jens

3

Hi Jens,

Thanks for the reply. I bought the license keys only without support so apparently I am not entitled for support even though the issue is with actually using the licenses.

Anyway I tried using curl.

On the SLES11SP3 (which has the SSL error), trying “curl https://nu.novell.com/repo/repoindex.xml?cookies=0&credentials=NCCcredentials” will return:

[CODE]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: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a “bundle”
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn’t adequate, 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.
[/CODE]

But if I try “curl -k https://nu.novell.com/repo/repoindex.xml?cookies=0&credentials=NCCcredentials”, I get:

Error 401: Full authentication is required to access this resource

On the SLES11SP2 trying curl without the -k flag I get the Error 401. So something must be wrong with the SLES11SP3.

Now I looked at a document at: https://www.suse.com/support/kb/doc.php?id=7002146

The date is correct, the Certificate validity is correct but I keep reading about SMT. What exactly is the SMT?

I have experience with Linux (mostly Redhat/Centos) but not much with SUSE. I thought that all I needed was to register the subscription, make sure I have the correct repositories and then I’ll be able to update. But I am seeing mention of an SMT server and client and that apparently I need both?

Is the SMT server like a gateway/proxy to download the packages? Can’t I just connect to the repos directly and update?

I saw some posts about running clientSetup4SMT.sh, but apparently you need to specify the host as in you need to create an SMT server.

I apologise for my ignorance, but I cannot find good articles that explain exactly how this works. I am piecing half answers together to try to figure this out. If possible all I want is to register, set SUSE repositories mentioned in the SCC on the system and update. But maybe I’m doing something wrong.

Thanks for the reply though. Much appreciated.

Robert

4

Hi Robert,

[QUOTE=rs2software;28820]Hi Jens,

Thanks for the reply. I bought the license keys only without support so apparently I am not entitled for support even though the issue is with actually using the licenses.[/QUOTE]

when I activated my last (“updates only”) license, I had a few days/weeks of complimentary installation support. But that was two years ago, things might have changed.

[QUOTE=rs2software;28820] Anyway I tried using curl.

On the SLES11SP3 (which has the SSL error), trying “curl https://nu.novell.com/repo/repoindex.xml?cookies=0&credentials=NCCcredentials” will return:

[CODE]curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed[/QUOTE]

You’ve successfully reproduced an isolated test case. This should not occur, typically the required “official” CA certificates should be available on your machine.

[QUOTE=rs2software;28820] But if I try “curl -k https://nu.novell.com/repo/repoindex.xml?cookies=0&credentials=NCCcredentials”, I get:

Error 401: Full authentication is required to access this resource

This is expected - you’re telling curl to ignore failing server certificate validation (a no-go for production systems) and the request parameters contain bogus values. You’ve proven that you can actually reach the server, but not much more information can be deducted from this result.

[QUOTE=rs2software;28820]On the SLES11SP2 trying curl without the -k flag I get the Error 401. So something must be wrong with the SLES11SP3.

Now I looked at a document at: https://www.suse.com/support/kb/doc.php?id=7002146

The date is correct, the Certificate validity is correct but I keep reading about SMT. What exactly is the SMT?[/QUOTE]

“SMT” is a no-cost add-on product to SLES that runs a local update server. While effectively your servers still register against NCC/SCC, this is routed through the local SMT server. On top, SMT mirrors update repositories and the clients are using these local repositories to fetch their updates. With SMT, it’s your job to maintain the server and CA certificates (as you’re running your own server),hence the TID.

As you were referencing that TID in your initial message, too, I got the impression you’re running an SMT server. But it seems you’re not? Anyway, as suse_register tries to contact nu.novell.com, the client obviously is not set up to use a local SMT server, so none of the measures in that TID apply to your situation…

You have not told us if you’re using https proxies - any chance that someone is interfering your HTTPS sessions?

The major question is: Why isn’t curl able to validate the nu.novell.com certificate… One way to trace this down is running “suse_register” under control of “strace” (which would log all system calls, i.e. the “open()” calls to the CA certificate store) and grep for “open()” call going to /etc/ssl/certs. It might well be the call trying to open the proper CA certificate file fails, you then could try to find out why it is so (missing symlinks, hence running c_rehash might help; missing certificates at all, so some package (openssl-certs RPM) might be missing).

Skip the SMT info for now, not needed, not applicable in your current situation. And yes, usually it’s nothing more that “install & register”.

[QUOTE=rs2software;28820]I apologise for my ignorance, but I cannot find good articles that explain exactly how this works. I am piecing half answers together to try to figure this out. If possible all I want is to register, set SUSE repositories mentioned in the SCC on the system and update. But maybe I’m doing something wrong.[/QUTE]

You’re trying to do the right thing. It’s just for some (not yet known) reason that the verification of the update server’s certificate fails. Other than requiring the “offical” CA certificates installed (“rpm -qi openssl-certs” should report the package as installed, “rpm -V openssl-certs” should produce no output), nothing special should be required on your side.

Regards,
Jens

Thanks for the reply though. Much appreciated.

Robert[/QUOTE]

Regards,
Jens

5

One would hope it was that simple.

Just my luck.

I am in fact using HTTPS/HTTP proxy and that was my first thought. But with and without it I had the same results and this worked on the SLES SP2 one.

This was extremely helpful. On the SLES SP3 the suse_register was not making any open() calls towards /etc/ssl/certs. I compared this with the SLES SP2 which was in fact making these calls. So I compared the directories and found the SLES SP3 /etc/ssl/certs directory had much less than the one for SLES SP2. I took a backup of the directory and just copied everything from the SLES SP2 to the SLES SP3 one and then it worked. I get “Registration finished successfully”. Finally.

In yast then in Support > Novell Customer Center Configuration > Registration status it says:

Registration Status at: 2015-07-22 15:22:50 Product: SUSE Linux Enterprise Server 11 SP3 (x86_64, ) Subscription: active (full version) Expiry: 2018-07-20 13:03:41

So that looks promising. But the repositories are empty and I cannot add more. When I try to add a repo which I got from the SCC like:
https://updates.suse.com/…/sle-11-x86_64

I get:

Permission to access 'https://updates.suse.com/repo/............/sle-11-x86_64/content' denied.

Now why is that?

I am using yast > Software > Software Repositories > Specify URL and paste the URL there.

This is also happening with the SLES SP2.

Thanks,
Robert

6

Hi Robert,

So I compared the directories and found the SLES SP3 /etc/ssl/certs directory had much less than the one for SLES SP2

did you run “rpm -qi openssl-certs” and/or “rpm -V openssl-certs” on the SP3 system? That’s the RPM that has the required CA certificates.

But the repositories are empty and I cannot add more.

Move aside ~root/.suse_register.log (so you’ll start with a fresh log) and run “suse_register -r” to re-establish the repository links… and if this doesn’t work, have a look at the log file to check for obvious errors.

(Manually adding repositories usually won’t get you far, stick with the suse_register route.)

Regards,
Jens

7

Hi Robert,

to check for obvious errors

re-reading this made it sound impolite… I meant to say to check for obvious errors and if none are found or aren’t solvable all by yourself, we’ll continue to debug :slight_smile:

Regards,
Jens

8

Hi Jens,

You were not impolite at all.

So suse_register -r should update the repos on its own? I did as you asked and moved the log and ran it again. It says “Registration finished successfully” but the repositories are still not populated.

I can see nothing (obviously) wrong with the log. It looks just like the system is sending its specs to Novell. Attached is the log.

I always suspected openssl-certs which is why if you remember I had posted the versions on my first post.

Here is the output of “rpm -qi openssl-certs”

Name : openssl-certs Relocations: (not relocatable) Version : 1.97 Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany Release : 0.3.1 Build Date: Wed Jun 4 23:21:05 2014 Install Date: Wed Apr 29 17:25:23 2015 Build Host: typhoon2 Group : Productivity/Networking/Security Source RPM: openssl-certs-1.97-0.3.1.src.rpm Size : 248870 License: Other uncritical OpenSource License; MPL 1.1/GPL 2.0/LGPL 2.1; MPL 1.1/GPL 2.0/LGPL 2.1 Signature : RSA/8, Wed Jun 4 23:21:16 2014, Key ID e3a5c360307e3d54 Packager : http://bugs.opensuse.org URL : http://www.mozilla.org Summary : CA certificates for OpenSSL Description : This package contains some CA root certificates for OpenSSL extracted from MozillaFirefox Distribution: SUSE Linux Enterprise 11

Output of rpm -V openssl-certs

rpm -V openssl-certs missing /etc/ssl/certs/ACCVRAIZ1.pem S.5....T /etc/ssl/certs/ACEDICOM_Root.pem S.5....T /etc/ssl/certs/AC_RaÃ*z_Certicámara_S_A_.pem S.5....T /etc/ssl/certs/A_Trust_nQual_03.pem missing /etc/ssl/certs/Actalis_Authentication_Root_CA.pem S.5....T /etc/ssl/certs/AddTrust_External_Root.pem S.5....T /etc/ssl/certs/AddTrust_Low_Value_Services_Root.pem S.5....T /etc/ssl/certs/AddTrust_Public_Services_Root.pem S.5....T /etc/ssl/certs/AddTrust_Qualified_Certificates_Root.pem S.5....T /etc/ssl/certs/AffirmTrust_Commercial.pem S.5....T /etc/ssl/certs/AffirmTrust_Networking.pem S.5....T /etc/ssl/certs/AffirmTrust_Premium.pem S.5....T /etc/ssl/certs/AffirmTrust_Premium_ECC.pem S.5....T /etc/ssl/certs/America_Online_Root_Certification_Authority_1.pem S.5....T /etc/ssl/certs/America_Online_Root_Certification_Authority_2.pem S.5....T /etc/ssl/certs/ApplicationCA_Japanese_Government.pem missing /etc/ssl/certs/Atos_TrustedRoot_2011.pem S.5....T /etc/ssl/certs/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.pem S.5....T /etc/ssl/certs/Baltimore_CyberTrust_Root.pem S.5....T /etc/ssl/certs/Buypass_Class_2_CA_1.pem missing /etc/ssl/certs/Buypass_Class_2_Root_CA.pem S.5....T /etc/ssl/certs/Buypass_Class_3_CA_1.pem missing /etc/ssl/certs/Buypass_Class_3_Root_CA.pem S.5....T /etc/ssl/certs/CA_Disig.pem missing /etc/ssl/certs/CA_Disig_Root_R1.pem missing /etc/ssl/certs/CA_Disig_Root_R2.pem S.5....T /etc/ssl/certs/CNNIC_ROOT.pem S.5....T /etc/ssl/certs/COMODO_Certification_Authority.pem S.5....T /etc/ssl/certs/COMODO_ECC_Certification_Authority.pem S.5....T /etc/ssl/certs/Camerfirma_Chambers_of_Commerce_Root.pem S.5....T /etc/ssl/certs/Camerfirma_Global_Chambersign_Root.pem S.5....T /etc/ssl/certs/Certigna.pem S.5....T /etc/ssl/certs/Certinomis_Autorit_Racine.pem S.5....T /etc/ssl/certs/Certplus_Class_2_Primary_CA.pem S.5....T /etc/ssl/certs/Certum_Root_CA.pem S.5....T /etc/ssl/certs/Certum_Trusted_Network_CA.pem S.5....T /etc/ssl/certs/Chambers_of_Commerce_Root_2008.pem missing /etc/ssl/certs/China_Internet_Network_Information_Center_EV_Certificates_Root.pem S.5....T /etc/ssl/certs/ComSign_Secured_CA.pem S.5....T /etc/ssl/certs/Comodo_AAA_Services_root.pem S.5....T /etc/ssl/certs/Comodo_Secure_Services_root.pem S.5....T /etc/ssl/certs/Comodo_Trusted_Services_root.pem S.5....T /etc/ssl/certs/Cybertrust_Global_Root.pem S.5....T /etc/ssl/certs/DST_ACES_CA_X6.pem S.5....T /etc/ssl/certs/DST_Root_CA_X3.pem missing /etc/ssl/certs/D_TRUST_Root_Class_3_CA_2_2009.pem missing /etc/ssl/certs/D_TRUST_Root_Class_3_CA_2_EV_2009.pem S.5....T /etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem S.5....T /etc/ssl/certs/DigiCert_Assured_ID_Root_CA.pem S.5....T /etc/ssl/certs/DigiCert_Global_Root_CA.pem S.5....T /etc/ssl/certs/DigiCert_High_Assurance_EV_Root_CA.pem S.5....T /etc/ssl/certs/EBG_Elektronik_Sertifika_Hizmet_SaÄlayıcısı.pem missing /etc/ssl/certs/EC_ACC.pem missing /etc/ssl/certs/EE_Certification_Centre_Root_CA.pem S.5....T /etc/ssl/certs/E_Guven_Kok_Elektronik_Sertifika_Hizmet_Saglayicisi.pem missing /etc/ssl/certs/E_Tugra_Certification_Authority.pem S.5....T /etc/ssl/certs/Entrust_Root_Certification_Authority.pem S.5....T /etc/ssl/certs/Entrust_net_Premium_2048_Secure_Server_CA.pem S.5....T /etc/ssl/certs/Entrust_net_Secure_Server_CA.pem S.5....T /etc/ssl/certs/Equifax_Secure_CA.pem S.5....T /etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem S.5....T /etc/ssl/certs/Equifax_Secure_eBusiness_CA_1.pem S.5....T /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem S.5....T /etc/ssl/certs/GeoTrust_Global_CA.pem S.5....T /etc/ssl/certs/GeoTrust_Global_CA_2.pem S.5....T /etc/ssl/certs/GeoTrust_Primary_Certification_Authority.pem S.5....T /etc/ssl/certs/GeoTrust_Primary_Certification_Authority_G2.pem S.5....T /etc/ssl/certs/GeoTrust_Primary_Certification_Authority_G3.pem S.5....T /etc/ssl/certs/GeoTrust_Universal_CA.pem S.5....T /etc/ssl/certs/GeoTrust_Universal_CA_2.pem S.5....T /etc/ssl/certs/GlobalSign_Root_CA.pem S.5....T /etc/ssl/certs/GlobalSign_Root_CA_R2.pem S.5....T /etc/ssl/certs/GlobalSign_Root_CA_R3.pem S.5....T /etc/ssl/certs/Global_Chambersign_Root_2008.pem S.5....T /etc/ssl/certs/Go_Daddy_Class_2_CA.pem S.5....T /etc/ssl/certs/Go_Daddy_Root_Certificate_Authority_G2.pem missing /etc/ssl/certs/Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem S.5....T /etc/ssl/certs/Hongkong_Post_Root_CA_1.pem S.5....T /etc/ssl/certs/IGC_A.pem S.5....T /etc/ssl/certs/Izenpe_com.pem S.5....T /etc/ssl/certs/Juur_SK.pem S.5....T /etc/ssl/certs/Microsec_e_Szigno_Root_CA.pem S.5....T /etc/ssl/certs/Microsec_e_Szigno_Root_CA_2009.pem S.5....T /etc/ssl/certs/NetLock_Arany_Class_Gold_F_tan_s_tv_ny.pem S.5....T /etc/ssl/certs/NetLock_Business_Class_B_Root.pem S.5....T /etc/ssl/certs/NetLock_Express_Class_C_Root.pem S.5....T /etc/ssl/certs/NetLock_Notary_Class_A_Root.pem S.5....T /etc/ssl/certs/Network_Solutions_Certificate_Authority.pem S.5....T /etc/ssl/certs/OISTE_WISeKey_Global_Root_GA_CA.pem missing /etc/ssl/certs/PSCProcert.pem S.5....T /etc/ssl/certs/QuoVadis_Root_CA.pem S.5....T /etc/ssl/certs/QuoVadis_Root_CA_2.pem S.5....T /etc/ssl/certs/QuoVadis_Root_CA_3.pem S.5....T /etc/ssl/certs/RSA_Root_Certificate_1.pem S.5....T /etc/ssl/certs/RSA_Security_2048_v3.pem S.5....T /etc/ssl/certs/Root_CA_Generalitat_Valenciana.pem S.5....T /etc/ssl/certs/SecureSign_RootCA11.pem S.5....T /etc/ssl/certs/SecureTrust_CA.pem S.5....T /etc/ssl/certs/Secure_Global_CA.pem S.5....T /etc/ssl/certs/Security_Communication_EV_RootCA1.pem missing /etc/ssl/certs/Security_Communication_RootCA2.pem S.5....T /etc/ssl/certs/Security_Communication_Root_CA.pem S.5....T /etc/ssl/certs/Sonera_Class_2_Root_CA.pem S.5....T /etc/ssl/certs/Staat_der_Nederlanden_Root_CA.pem S.5....T /etc/ssl/certs/Staat_der_Nederlanden_Root_CA_G2.pem S.5....T /etc/ssl/certs/Starfield_Class_2_CA.pem S.5....T /etc/ssl/certs/Starfield_Root_Certificate_Authority_G2.pem S.5....T /etc/ssl/certs/Starfield_Services_Root_Certificate_Authority_G2.pem missing /etc/ssl/certs/StartCom_Certification_Authority.1.pem S.5....T /etc/ssl/certs/StartCom_Certification_Authority.pem missing /etc/ssl/certs/StartCom_Certification_Authority_G2.pem S.5....T /etc/ssl/certs/SwissSign_Gold_CA_G2.pem S.5....T /etc/ssl/certs/SwissSign_Silver_CA_G2.pem S.5....T /etc/ssl/certs/Swisscom_Root_CA_1.pem missing /etc/ssl/certs/Swisscom_Root_CA_2.pem missing /etc/ssl/certs/Swisscom_Root_EV_CA_2.pem S.5....T /etc/ssl/certs/TC_TrustCenter_Class_2_CA_II.pem S.5....T /etc/ssl/certs/TC_TrustCenter_Class_3_CA_II.pem S.5....T /etc/ssl/certs/TC_TrustCenter_Universal_CA_I.pem S.5....T /etc/ssl/certs/TDC_Internet_Root_CA.pem S.5....T /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem S.5....T /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_2.pem missing /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_2007.pem missing /etc/ssl/certs/TWCA_Global_Root_CA.pem S.5....T /etc/ssl/certs/TWCA_Root_Certification_Authority.pem missing /etc/ssl/certs/T_TeleSec_GlobalRoot_Class_2.pem missing /etc/ssl/certs/T_TeleSec_GlobalRoot_Class_3.pem S.5....T /etc/ssl/certs/Taiwan_GRCA.pem missing /etc/ssl/certs/TeliaSonera_Root_CA_v1.pem S.5....T /etc/ssl/certs/Thawte_Premium_Server_CA.pem S.5....T /etc/ssl/certs/Thawte_Server_CA.pem missing /etc/ssl/certs/Trustis_FPS_Root_CA.pem S.5....T /etc/ssl/certs/TÃBÄ°TAK_UEKAE_Kök_Sertifika_Hizmet_SaÄlayıcısı_Sürüm_3.pem S.5....T /etc/ssl/certs/UTN_DATACorp_SGC_Root_CA.pem S.5....T /etc/ssl/certs/UTN_USERFirst_Hardware_Root_CA.pem S.5....T /etc/ssl/certs/ValiCert_Class_1_VA.pem S.5....T /etc/ssl/certs/ValiCert_Class_2_VA.pem S.5....T /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_G4.pem S.5....T /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem S.5....T /etc/ssl/certs/VeriSign_Universal_Root_Certification_Authority.pem S.5....T /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.1.pem S.5....T /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem S.5....T /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority_G2.pem S.5....T /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority_G3.pem S.5....T /etc/ssl/certs/Verisign_Class_4_Public_Primary_Certification_Authority_G3.pem S.5....T /etc/ssl/certs/Visa_eCommerce_Root.pem S.5....T /etc/ssl/certs/WellsSecure_Public_Root_Certificate_Authority.pem S.5....T /etc/ssl/certs/XRamp_Global_CA_Root.pem S.5....T /etc/ssl/certs/certSIGN_ROOT_CA.pem S.5....T /etc/ssl/certs/ePKI_Root_Certification_Authority.pem S.5....T /etc/ssl/certs/thawte_Primary_Root_CA.pem S.5....T /etc/ssl/certs/thawte_Primary_Root_CA_G2.pem S.5....T /etc/ssl/certs/thawte_Primary_Root_CA_G3.pem

I think there would have been a lot more missing before. If I remember correctly, this version I got from openSUSE after I got the SSL error when running suse_register.

Here is the suse_register log. https://www.dropbox.com/s/mxj1uac8e2uneuy/suse_register.log?dl=0

Thanks,
Robert

9

Hi Robert,

I always suspected openssl-certs which is why if you remember I had posted the versions on my first post.

sorry, that info completely slipped by :-[

Very interesting, a number of missing files from the package: They were installed initially, else RPM wouldn’t try to locate them. Something messed with your system. If you cannot trace this back to some known root cause (like some installer script), I strongly suggest to run a global “rpm -Vall” to verify all RPMs and to detect other files missing as well.

Be prepared to see a number of modified files - but only those marked as configuration files (via a “c” between the flags and the file name) should be altered, other file types should be looked after!

And please reinstall the rpm via YaST or zypper to have the current (and the currently missing) certificates installed.

Regards,
Jens

10

[QUOTE=jmozdzen;28837]Very interesting, a number of missing files from the package: They were installed initially, else RPM wouldn’t try to locate them. Something messed with your system. If you cannot trace this back to some known root cause (like some installer script), I strongly suggest to run a global “rpm -Vall” to verify all RPMs and to detect other files missing as well.

Be prepared to see a number of modified files - but only those marked as configuration files (via a “c” between the flags and the file name) should be altered, other file types should be looked after![/QUOTE]

I ran rpm -Vall and I see mostly size, md5 and time differs. As you said this is to be expected for config files. I have no missing files except for the ones in /etc/ssl/certs and I see all of the remaining certs in that folder with size, md5 and time difference. But that was expected since I copied them from another system. At least there are no more missing files though.

I cannot reinstall the RPM because I have no repositories available.

Thanks,
Robert

11

Hi Robert,

I’ve had a look at the log file and see nothing obviously wrong on your side - but let me check with my backends to make sure.

I cannot reinstall the RPM because I have no repositories available.

I’d have guessed you have the installation medium available… if not, you can download the ISO from SUSE servers :wink: (https://download.suse.com/Download?buildid=Q_VbW21BiB4~)

Regards,
Jens

12

Thanks Jens for the reply. I have installed the updated openssl-certs with your help which fixed the certificates problems. I am still waiting for suse_register to populate the repositories.

Regards,
Robert