# Problems registering and updating
**URL:** https://forums.suse.com/t/problems-registering-and-updating/27260
**Category:** SLES Updates
**Created:** [July 21, 2015, 4:45pm UTC](https://forums.suse.com/t/problems-registering-and-updating/27260 "2015-07-21T16:45:00Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@rs2software](https://forums.suse.com/u/rs2software)
#### Post date: [July 21, 2015, 4:45pm UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/1 "2015-07-21T16:45:00Z")
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](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](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/](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](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
```auto
/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
```auto
/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.
---
### Author:  [@Jens-U](https://forums.suse.com/u/Jens-U)
#### Post date: [July 21, 2015, 5:30pm UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/2 "2015-07-21T17:30:46Z")
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](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](http://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 😉
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
---
### Author:  [@rs2software](https://forums.suse.com/u/rs2software)
#### Post date: [July 22, 2015, 11:33am UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/3 "2015-07-22T11:33:58Z")
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](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](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](https://nu.novell.com/repo/repoindex.xml?cookies=0&credentials=NCCcredentials)”, I get:
```auto
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](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
---
### Author:  [@Jens-U](https://forums.suse.com/u/Jens-U)
#### Post date: [July 22, 2015, 2:30pm UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/4 "2015-07-22T14:30:21Z")
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](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](https://nu.novell.com/repo/repoindex.xml?cookies=0&credentials=NCCcredentials)”, I get:
```auto
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](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](http://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](http://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).
> [@rs2software;28820](#):
>
> 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?
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
---
### Author:  [@rs2software](https://forums.suse.com/u/rs2software)
#### Post date: [July 22, 2015, 4:40pm UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/5 "2015-07-22T16:40:07Z")
> [@jmozdzen;28828](#):
>
> 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.
One would hope it was that simple.
> [@jmozdzen;28828](#):
>
> You’ve successfully reproduced an isolated test case. This should not occur, typically the required “official” CA certificates should be available on your machine.
Just my luck.
> [@jmozdzen;28828](#):
>
> You have not told us if you’re using https proxies - any chance that someone is interfering your HTTPS sessions?
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.
> [@jmozdzen;28828](#):
>
> The major question is: Why isn’t curl able to validate the [nu.novell.com](http://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).
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](https://updates.suse.com/.............../sle-11-x86_64)
I get:
```auto
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
---
### Author:  [@Jens-U](https://forums.suse.com/u/Jens-U)
#### Post date: [July 22, 2015, 5:22pm UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/6 "2015-07-22T17:22:55Z")
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
---
### Author:  [@Jens-U](https://forums.suse.com/u/Jens-U)
#### Post date: [July 22, 2015, 5:25pm UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/7 "2015-07-22T17:25:51Z")
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 🙂
Regards,
Jens
---
### Author:  [@rs2software](https://forums.suse.com/u/rs2software)
#### Post date: [July 22, 2015, 6:02pm UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/8 "2015-07-22T18:02:02Z")
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](https://www.dropbox.com/s/mxj1uac8e2uneuy/suse_register.log?dl=0)
Thanks,
Robert
---
### Author:  [@Jens-U](https://forums.suse.com/u/Jens-U)
#### Post date: [July 22, 2015, 6:24pm UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/9 "2015-07-22T18:24:55Z")
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
---
### Author:  [@rs2software](https://forums.suse.com/u/rs2software)
#### Post date: [July 23, 2015, 11:06am UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/10 "2015-07-23T11:06:17Z")
[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.
> [@jmozdzen;28837](#):
>
> And please reinstall the rpm via YaST or zypper to have the current (and the currently missing) certificates installed.
I cannot reinstall the RPM because I have no repositories available.
Thanks,
Robert
---
### Author:  [@Jens-U](https://forums.suse.com/u/Jens-U)
#### Post date: [July 23, 2015, 11:59am UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/11 "2015-07-23T11:59:00Z")
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 😉 ([https://download.suse.com/Download?buildid=Q\_VbW21BiB4~](https://download.suse.com/Download?buildid=Q_VbW21BiB4~))
Regards,
Jens
---
### Author:  [@rs2software](https://forums.suse.com/u/rs2software)
#### Post date: [July 23, 2015, 2:42pm UTC](https://forums.suse.com/t/problems-registering-and-updating/27260/12 "2015-07-23T14:42:00Z")
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