SEP for linux installation will fail if missing DigiCert Global Root G2 in trust store
Article ID: 257185
Updated On:
Products
Issue/Introduction
The installation of SEP for Linux or the creation of offline package will fail in case of missing the root certificate of DigiCert Global Root G2 in the trust store
The installation failure will look like below
[root@<Server_Name> ~]# ./LinuxInstaller
YUM Repo communication error:
/=============================================================================\
| Loaded plugins: fastestmirror |
| Loading mirror speeds from cached hostfile |
| https://linux-repo.us.securitycloud.symantec.com/SAL/1.1/rhel7/x86_64/repod |
| ata/repomd.xml: [Errno 14] curl#60 - "Peer's Certificate issuer is not |
| recognized." |
| Trying other mirror. |
| It was impossible to connect to the CentOS servers. |
| This could mean a connectivity issue in your environment, such as the |
| requirement to configure a proxy, |
| or a transparent proxy that tampers with TLS security, or an incorrect |
| system clock. |
| You can try to solve this issue by using the instructions on |
| https://wiki.centos.org/yum-errors |
| If above article doesn't help to resolve this issue please use |
| https://bugs.centos.org/. |
| |
| Metadata Cache Created |
\=============================================================================/
NOTICE: Unable to communicate with repository. Check repo file /etc/yum.repos.d/sdcss.repo
The offline package creation will look similar to above.
This failure logs can be found as well in the following log file /var/log/sdcsslog/sdcss_install.log
Testing connectivity to https://linux-repo.us.securitycloud.symantec.com/SAL/1.1/rhel7/x86_64/repodata/repomd.xml fails
[root@<Server_Name> ~]# curl -vvv https://linux-repo.us.securitycloud.symantec.com/SAL/1.1/rhel7/x86_64/repodata/repomd.xml
* About to connect() to linux-repo.us.securitycloud.symantec.com port 443 (#0)
* Trying 144.49.210.144...
* Connected to linux-repo.us.securitycloud.symantec.com (144.49.210.144) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* Server certificate:
* subject: CN=securitycloud.symantec.com,O=Broadcom Inc,L=San Jose,ST=California,C=US
* start date: Oct 19 00:00:00 2022 GMT
* expire date: Oct 19 23:59:59 2023 GMT
* common name: securitycloud.symantec.com
* issuer: CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1,O=DigiCert Inc,C=US
* NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER)
* Peer's Certificate issuer is not recognized.
* Closing connection 0
curl: (60) Peer's Certificate issuer is not recognized.
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.
Environment
Release : 14.3 RU1 and later
Cause
SEP installer needs to download the following file repomd.xml from the following link https://linux-repo.us.securitycloud.symantec.com/SAL/1.1/rhel7/x86_64/repodata/repomd.xml using HTTPS.
Due to not having the root certificate of DigiCert Global Root G2 trusted by the Linux host, the TLS handshake will fail.
Resolution
Trusting the root CA certificate in the trust store of the OS machine where the user runs the installer.
Below is a demo of adding the certificate to the trust store in Centos 7, for any other Linux OS please conslut the documentation of the Linux distribution vendor.
Step 1: Verify if the certificate exists in the trust store:
If below command doesn't return any outputs, it means the certificate doesn't exist in the trust store of the Linux machine
[root@<Server_Name> ~]# openssl crl2pkcs7 -nocrl -certfile /etc/pki/tls/certs/ca-bundle.crt | openssl pkcs7 -print_certs -noout
| grep "DigiCert Global Root G2"
Step 2: Upload the certificate to your Linux machine
[root@<Server_Name> ~]# cat digiCert.crt
-----BEGIN CERTIFICATE-----
MIIDjjCCAnagAwIBAgIQAzrx5qcRqaC7KGSxHQn65TANBgkqhkiG9w0BAQsFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBH
MjAeFw0xMzA4MDExMjAwMDBaFw0zODAxMTUxMjAwMDBaMGExCzAJBgNVBAYTAlVT
MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j
b20xIDAeBgNVBAMTF0RpZ2lDZXJ0IEdsb2JhbCBSb290IEcyMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuzfNNNx7a8myaJCtSnX/RrohCgiN9RlUyfuI
2/Ou8jqJkTx65qsGGmvPrC3oXgkkRLpimn7Wo6h+4FR1IAWsULecYxpsMNzaHxmx
1x7e/dfgy5SDN67sH0NO3Xss0r0upS/kqbitOtSZpLYl6ZtrAGCSYP9PIUkY92eQ
q2EGnI/yuum06ZIya7XzV+hdG82MHauVBJVJ8zUtluNJbd134/tJS7SsVQepj5Wz
tCO7TG1F8PapspUwtP1MVYwnSlcUfIKdzXOS0xZKBgyMUNGPHgm+F6HmIcr9g+UQ
vIOlCsRnKPZzFBQ9RnbDhxSJITRNrw9FDKZJobq7nMWxM4MphQIDAQABo0IwQDAP
BgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUTiJUIBiV
5uNu5g/6+rkS7QYXjzkwDQYJKoZIhvcNAQELBQADggEBAGBnKJRvDkhj6zHd6mcY
1Yl9PMWLSn/pvtsrF9+wX3N3KjITOYFnQoQj8kVnNeyIv/iPsGEMNKSuIEyExtv4
NeF22d+mQrvHRAiGfzZ0JFrabA0UWTW98kndth/Jsw1HKj2ZL7tcu7XUIOGZX1NG
Fdtom/DzMNU+MeKNhJ7jitralj41E6Vf8PlwUHBHQRFXGU7Aj64GxJUTFy8bJZ91
8rGOmaFvE7FBcf6IKshPECBV1/MUReXgRPTqh5Uykw7+U0b6LJ3/iyK5S9kJRaTe
pLiaWN0bfVKfjllDiIGknibVb63dDcY3fe0Dkhvld1927jyNxF1WW6LZZm6zNTfl
MrY=
-----END CERTIFICATE-----
Step 3: Add the certificate to the trust store
[root@<Server_Name> ~]# sudo update-ca-trust --import --file digiCert.crt
Step 4: Verify that the certificate exists in the trust store
[root@<Server_Name> ~]# openssl crl2pkcs7 -nocrl -certfile /etc/pki/tls/certs/ca-bundle.crt | openssl pkcs7 -print_certs -noout | grep "DigiCert Global Root G2"
subject=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2
**NOTE**
You can verify the presence of the root certificate by inspecting the ca-bundle with the following commands:
To list all certificates within the ca-bundle, use:
cat /etc/pki/tls/certs/ca-bundle.crt | grep "#"
This will display the comments in the file, indicating the certificate names.
To search for DigiCert certificates specifically, use:
cat /etc/pki/tls/certs/ca-bundle.crt | grep "DigiCert"
This will filter the entries related to DigiCert within the ca-bundle.
These commands allow for quick identification and verification of certificates within the system's trusted root store.
Step 5: Perform the curl test again
[root@<Server_Name> ~]# curl -vvv https://linux-repo.us.securitycloud.symantec.com/SAL/1.1/rhel7/x86_64/repodata/repomd.xml
* About to connect() to linux-repo.us.securitycloud.symantec.com port 443 (#0)
* Trying 144.49.210.144...
* Connected to linux-repo.us.securitycloud.symantec.com (144.49.210.144) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=securitycloud.symantec.com,O=Broadcom Inc,L=San Jose,ST=California,C=US
* start date: Oct 19 00:00:00 2022 GMT
* expire date: Oct 19 23:59:59 2023 GMT
* common name: securitycloud.symantec.com
* issuer: CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1,O=DigiCert Inc,C=US
> GET /SAL/1.1/rhel7/x86_64/repodata/repomd.xml HTTP/1.1
> User-Agent: curl/7.29.0
> Host: linux-repo.us.securitycloud.symantec.com
> Accept: */*
>
< HTTP/1.1 200 OK
Feedback
