we are enjoying a flavour of the notorious “unable to get local issuer certificate” behaviour with our virtual SLES 12 SP 1 servers installed and registered a few months ago. Whenever I try to add “Extensions and Modules from Registration Server…” it fails with the aforementioned message. As does [FONT=Courier New]SUSEConnect --debug[/FONT]. Updating using update repository “SLES12-SP1-Updates” from “https://updates.suse.com…”, works like a charm, though. [FONT=Courier New]Curl[/FONT]ing to “https://updates.suse.com” produces 403 messages, but no certificate problem.
[FONT=Courier New]/etc/pki/trust/anchors[/FONT] is plain empty, but contrary to document 7017147 there is no directory [FONT=Courier New]/usr/share/rhn[/FONT] either. In fact there is no file with a name containing “rhn” systemwide.
Are there any known measures more appropriate for our SLES 12 SP 1 installations than document 7017147?
we are enjoying a flavour of the notorious “unable to get local issuer
certificate” behaviour with our virtual SLES 12 SP 1 servers installed
and registered a few months ago. Whenever I try to add “Extensions and
Modules from Registration Server…” it fails with the aforementioned
message. As does SUSEConnect --debug. Updating using update repository
“SLES12-SP1-Updates” from “https://updates.suse.com…”, works like a
charm, though. Curling to “https://updates.suse.com” produces 403
messages, but no certificate problem.
/etc/pki/trust/anchors is plain empty, but contrary to document 7017147
there is no directory /usr/share/rhn either. In fact there is no file
with a name containing “rhn” systemwide.
Are there any known measures more appropriate for our SLES 12 SP 1
installations than document 7017147?[/color]
Are your servers registered to a local SUSE Manager (or SMT)
server or are they registered directly with SUSE Customer Center
(SCC)?