SSL order issued + Installation

Can not open Wildcard certificate / folder looks empty
Question
A wildcard certificate is issued, but I receive an error when unpacking the certificate archive downloaded, what’s wrong?
Once i open the zipfile, the folder looks empty.
Answer
Sectigo (former Comodo) Wildcard certificates have a “*” in the file names, which is considered a prohibited characters in default Windows archiver, as a result - your activation tool returns an error or the folder will appear empty. Try using a free achiever tool like 7-Zip etc.: it mitigates this problem by renaming the files containing ‘*’ automatically.

Certificate is not trusted after installation
Symptoms
After installing certificate you check the website and are presented with an SSL error:
The certificate is not trusted!
This means that you are not presented with a full chain of trust of the certificate.
Cause
SSL Certificate chain is incomplete. Some components are missed.
Use the full root and intermediate certificates when installing the certificate.
Resolution
Please use the full root and intermediate certificates when installing the certificate, these can be found in this knowledge base article.
You can check your installation onthis website, we use it often as it has a lot of checks that can give you plenty of information about your server's security
Or usethe tool from Sectigo, when you are using a Comodo (Sectigo) certificate.

How to generate Public Key (PFX)
If your server/device requires a different certificate format other than Base64 encoded X.509, a third party tool such as OpenSSL can be used to convert the certificate into the appropriate format.
PFX is a container used for MS Windows-based OS that stores your private key, certificate, intermediate certificate and root ceritifcate in one single file.
Type
PEM
P7B (PKCS#7)
PFX (P12/PKCS#12)
DER
Platforms
Apache and similar
MS Windows / Java Tomcat
MS Windows machines
Java platforms
Private key
Can be included
Not included
Can be included
Not included
Archive downloaded from SSL Panel does not include PFX due to security reasons (we do not store private keys, only show during CSR generation and sent to owner email) but you can generate PFX by yourself. Be sure OpenSSL tool is presented on your system.
Answer
1. Copy and paste the private key (find an email in your inbox with subject: "Your generated CSR and keys for domain ..." and sender: "no-reply@sslpanel.io") to the text editor and save it as a file named 'private.key'.
2. Extract P7B from the certificate archive (stores certificate, intermediate certificate, and root certificate), rename it to p7b.p7b, and put it in the same folder where the 'private.key' file is located.
Note: If you are using a Windows machine and can't find certificate files for Wildcard SSL orders in the folders using File Explorer, we recommend using 7-Zip to extract the zip archive.
3. Recode P7B into PEM format using OpenSSL command:
openssl pkcs7 -print_certs -in p7b.p7b -out certificate.pem
New file 'certificate.pem' should appear in the folder 
4. Generate PFX with command:
openssl pkcs12 -export -in certificate.pem -inkey private.key -out mycert.pfx
where 'mycert.pfx' - required name of our new PFX
5. Input and confirm password (use strong password because of PFX besides certificate, intermediate certificate and root certificates also stores your private key). You can generate strong password with e.g. command:
openssl rand -base64 32
Unauthorised access to PFX can cause certificate compromise.
6. 'mycert.pfx' will appear in folder. Well done!
The PFX was successfully generated and could be used for further operations.
 

Installing a Wildcard SSL Certificate on Multiple Servers
Question
Is it possible to install a Wildcard (.*) SSL Certificate on Multiple servers?
Answer
Yes.
The number of servers on which an SSL certificate is installed is not limited.
Follow the instructions for Comodo (Sectigo).
Having trouble to open the zip file and does the file look empty?
Please review this article to resolve that.

List of Root and Intermediate certificates
Question
Where to find the root and intermediate certificates for Comodo (Sectigo) certificates?
Answer
SSL installation requires root and intermediate certificates forming a "chain of trust".
If at least one component is missed chain will be marked as non-trusted by some browsers.
Please, find the updated list of all the CA intermediate and root here.
"Comodo" renamed into "Sectigo" since 01-11-18.
Since 14-01-19 major part of Comodo products changed root certificates.
Products active after 14-01-19 use new root during activation and reissue.
Products active before 14-01-18 using old "Comodo" root for activation and use the same for reissue.
Actual for certificates issued before 14.01.19 and actual for their further reissues.
EssentialSSL (SHA-1/SHA256)
EssentialSSL Wildcard (SHA-1/SHA-256)
PositiveSSL
PositiveSSL Wildcard
PositiveSSL Multi-Domain
EV SSL (SHA-1/SHA-256)
EVSSL multi-domain
InstantSSL
InstantSSL Pro
PremiumSSL
PremiumSSL Wildcard
Unified Communications Certificate (UCC)
Actual for certificates issued since 14.01.19 and actual for their further reissues.
ROOT Root: Sectigo InstantSSL (issued since 14.01.2019)
INTERMEDIATE Intermediate: Sectigo InstantSSL (issued since 14.01.2019)
ROOT Root: Sectigo InstantSSL Pro (issued since 14.01.2019)
INTERMEDIATE Intermediate: InstantSSL Pro (issued since 14.01.2019)
ROOT Root: Sectigo PositiveSSL (issued since 14.01.2019)
INTERMEDIATE Intermediate: Sectigo PositiveSSL (issued since 14.01.2019)
ROOT Root: Sectigo PositiveSSL Wildcard (issued since 14.01.2019)
INTERMEDIATE Intermediate: Sectigo PositiveSSL Wildcard (issued since 14.01.2019)
ROOT Root: Sectigo PositiveSSL MultiDomain (issued since 14.01.2019)
INTERMEDIATE Intermediate: Sectigo PositiveSSL MultiDomain (issued since 14.01.2019)
ROOT Root: Sectigo EssentialSSL (issued since 14.01.2019)
INTERMEDIATE Intermediate: Sectigo EssentialSSL (issued since 14.01.2019)
ROOT Root: Sectigo PremiumSSL (issued since 14.01.2019)
INTERMEDIATE Intermediate: Sectigo PremiumSSL (issued since 14.01.2019)
ROOT Root: Sectigo PremiumSSL Wildcard (issued since 14.01.2019)
INTERMEDIATE Intermediate: Sectigo PremiumSSL Wildcard (issued since 14.01.2019)
ROOT Root: Sectigo UCC EV (issued since 14.01.2019)
INTERMEDIATE Intermediate: UCC EV (issued since 14.01.2019)
ROOT Root: Sectigo EVSSL (issued since 14.01.2019)
INTERMEDIATE Intermediate: EVSSL (issued since 14.01.2019)
ROOT Root: Sectigo EVSSL Multi-Domain (issued since 14.01.2019)
INTERMEDIATE Intermediate: EVSSL Multi-Domain (issued since 14.01.2019)

Making SSL work on a legacy devices
Question:
SSL Certificate is not recognized as valid on legacy devices (Android 4X, Old IOS). How to fix?
Answer:
That is possible for Comodo Certificates.
The main thing you should know is that you will need to make some changes to a certificates chain.
On an example of Apache 2.4.9 please follow a guide on how to set up SSL.
After everything has been done and your website resolves as HTTPS correctly, do the following:
1. Find and open your current certificate in a text editor ;
(You can check configuration to find a path to a certificate: e.g. /etc/apache2/sites-enabled/000-default.conf for Ubuntu includes path for certificate and string 'SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem' shows certificate location itself. From system to system paths may vary.)
2. Open your site certificate in a text editor.
Add there two blocks including root and specific intermediate chain below site certificate ;
For example if certificate initially included:
-----BEGIN CERTIFICATE-----
MIIFtDCCBJygAwIBAgIQE553nZKKeoPq1kf6iN7auDANBgkqhkiG9w0BAQsFADCB
jzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQD
Ey5TZWN0aWdvIFJTQSBEb21haW4gVmFsaWRhdGlvbiBTZWN1cmUgU2VydmVyIENB
MB4XDTIwMDQyMDAwMDAwMFoXDTIxMDQyMTIzNTk1OVowFTETMBEGA1UEAxMKaG9z
dGVkLmZ1bjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALIvIh7pLEwG
lC84+wuzemtOi5zWYpXg2gLIp+Hr6vWofuYzbxKhHQLlsUuHJ3mMRQhRcGWTmI1v
C2qocDRTpy804yPpz+nrVhhevZniW9MPg1maQgPOcdbUINzWdUT6WZEFg9DVrOj/
NQRFXcducjtWHwE3dMy7ws4JreoI8epNARmrWFTHshWxO3cL4b0LLRbOG16B6s09
BfDv5NF2Wm4EHv98mgWHwePQqdQ3XZ/kWLkcV3oCeK3t+J8s8PztSKdeEG/hbL5i
yeljU/sfVm+1TFYPRdcyeu30eV4otEWHOeipfPUxI4QC4yIS5uyOzsjQx/4U8ctU
Y7wle3NTnfkCAwEAAaOCAoMwggJ/MB8GA1UdIwQYMBaAFI2MXsRUrYrhd+mb+ZsF
4bgBjWHhMB0GA1UdDgQWBBQSTE/dgNt43q4GcG7m5bjVBrib7jAOBgNVHQ8BAf8E
BAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUH
AwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUFBwIBFhdodHRw
czovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUFBwEBBHgwdjBP
BggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBRG9t
YWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAjBggrBgEFBQcwAYYXaHR0
cDovL29jc3Auc2VjdGlnby5jb20wJQYDVR0RBB4wHIIKaG9zdGVkLmZ1boIOd3d3
Lmhvc3RlZC5mdW4wggEFBgorBgEEAdZ5AgQCBIH2BIHzAPEAdgB9PvL4j/+IVWgk
wsDKnlKJeSvFDngJfy5ql2iZfiLw1wAAAXGXTEtUAAAEAwBHMEUCIAr63zpOX094
//t4bwpGl9sMmoFOwFkqzK+ldPjACHeGAiEA3fqT9t7ws8m/PrrNXBgeIQnq4OKm
9QYjiytlH2kEoPUAdwCUILwejtWNbIhzH4KLIiwN0dpNXmxPlD1h204vWE2iwgAA
AXGXTEt8AAAEAwBIMEYCIQDrzLW8UyfmVsnXwatKVgVf3eChRlktRq1C9EBn3BDX
/QIhAI2VSJJjUQ01YQGyl7rWPYEh86Vg5/lzoLE9ibSXZvJfMA0GCSqGSIb3DQEB
CwUAA4IBAQAEVJKyyq/alWNuxDDcjE9IxQ6sjTN+eJFYWzLuybYgLSh+tj0gMxUt
2fMzvgMwtHZZJYX2LRhJxUlJyaEQtYfiPV+P7v5DcpZdc3zj7idXVf+p1CPEkLo4
HA0YwEYvbSAjueiuDMVXxQ0DWj+2hCeyguHlrN6Ld/nA8FbZMZqPy0FidLS9AOuo
kOEcEobe0EFnhRdKNjgmv4kZJAI/R/1U75DDYkx2GvIRRi52Rclko6cBuDgxVSfY
GYB6D11iZGeo/VGMKRmCcR4kf+sxsEHzBHUvgwHhDVJ7xC5HttxdPfP1CVQjdjJy
/mn/qbHuybKBmhEfKDIY7ARSgGH+c7ym
-----END CERTIFICATE-----
Then after changes it will look like:
-----BEGIN CERTIFICATE-----
MIIFtDCCBJygAwIBAgIQE553nZKKeoPq1kf6iN7auDANBgkqhkiG9w0BAQsFADCB
jzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQD
Ey5TZWN0aWdvIFJTQSBEb21haW4gVmFsaWRhdGlvbiBTZWN1cmUgU2VydmVyIENB
MB4XDTIwMDQyMDAwMDAwMFoXDTIxMDQyMTIzNTk1OVowFTETMBEGA1UEAxMKaG9z
dGVkLmZ1bjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALIvIh7pLEwG
lC84+wuzemtOi5zWYpXg2gLIp+Hr6vWofuYzbxKhHQLlsUuHJ3mMRQhRcGWTmI1v
C2qocDRTpy804yPpz+nrVhhevZniW9MPg1maQgPOcdbUINzWdUT6WZEFg9DVrOj/
NQRFXcducjtWHwE3dMy7ws4JreoI8epNARmrWFTHshWxO3cL4b0LLRbOG16B6s09
BfDv5NF2Wm4EHv98mgWHwePQqdQ3XZ/kWLkcV3oCeK3t+J8s8PztSKdeEG/hbL5i
yeljU/sfVm+1TFYPRdcyeu30eV4otEWHOeipfPUxI4QC4yIS5uyOzsjQx/4U8ctU
Y7wle3NTnfkCAwEAAaOCAoMwggJ/MB8GA1UdIwQYMBaAFI2MXsRUrYrhd+mb+ZsF
4bgBjWHhMB0GA1UdDgQWBBQSTE/dgNt43q4GcG7m5bjVBrib7jAOBgNVHQ8BAf8E
BAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUH
AwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUFBwIBFhdodHRw
czovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUFBwEBBHgwdjBP
BggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBRG9t
YWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAjBggrBgEFBQcwAYYXaHR0
cDovL29jc3Auc2VjdGlnby5jb20wJQYDVR0RBB4wHIIKaG9zdGVkLmZ1boIOd3d3
Lmhvc3RlZC5mdW4wggEFBgorBgEEAdZ5AgQCBIH2BIHzAPEAdgB9PvL4j/+IVWgk
wsDKnlKJeSvFDngJfy5ql2iZfiLw1wAAAXGXTEtUAAAEAwBHMEUCIAr63zpOX094
//t4bwpGl9sMmoFOwFkqzK+ldPjACHeGAiEA3fqT9t7ws8m/PrrNXBgeIQnq4OKm
9QYjiytlH2kEoPUAdwCUILwejtWNbIhzH4KLIiwN0dpNXmxPlD1h204vWE2iwgAA
AXGXTEt8AAAEAwBIMEYCIQDrzLW8UyfmVsnXwatKVgVf3eChRlktRq1C9EBn3BDX
/QIhAI2VSJJjUQ01YQGyl7rWPYEh86Vg5/lzoLE9ibSXZvJfMA0GCSqGSIb3DQEB
CwUAA4IBAQAEVJKyyq/alWNuxDDcjE9IxQ6sjTN+eJFYWzLuybYgLSh+tj0gMxUt
2fMzvgMwtHZZJYX2LRhJxUlJyaEQtYfiPV+P7v5DcpZdc3zj7idXVf+p1CPEkLo4
HA0YwEYvbSAjueiuDMVXxQ0DWj+2hCeyguHlrN6Ld/nA8FbZMZqPy0FidLS9AOuo
kOEcEobe0EFnhRdKNjgmv4kZJAI/R/1U75DDYkx2GvIRRi52Rclko6cBuDgxVSfY
GYB6D11iZGeo/VGMKRmCcR4kf+sxsEHzBHUvgwHhDVJ7xC5HttxdPfP1CVQjdjJy
/mn/qbHuybKBmhEfKDIY7ARSgGH+c7ym
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGEzCCA/ugAwIBAgIQfVtRJrR2uhHbdBYLvFMNpzANBgkqhkiG9w0BAQwFADCB
iDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0pl
cnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNV
BAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgx
MTAyMDAwMDAwWhcNMzAxMjMxMjM1OTU5WjCBjzELMAkGA1UEBhMCR0IxGzAZBgNV
BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UE
ChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQDEy5TZWN0aWdvIFJTQSBEb21haW4g
VmFsaWRhdGlvbiBTZWN1cmUgU2VydmVyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA1nMz1tc8INAA0hdFuNY+B6I/x0HuMjDJsGz99J/LEpgPLT+N
TQEMgg8Xf2Iu6bhIefsWg06t1zIlk7cHv7lQP6lMw0Aq6Tn/2YHKHxYyQdqAJrkj
eocgHuP/IJo8lURvh3UGkEC0MpMWCRAIIz7S3YcPb11RFGoKacVPAXJpz9OTTG0E
oKMbgn6xmrntxZ7FN3ifmgg0+1YuWMQJDgZkW7w33PGfKGioVrCSo1yfu4iYCBsk
Haswha6vsC6eep3BwEIc4gLw6uBK0u+QDrTBQBbwb4VCSmT3pDCg/r8uoydajotY
uK3DGReEY+1vVv2Dy2A0xHS+5p3b4eTlygxfFQIDAQABo4IBbjCCAWowHwYDVR0j
BBgwFoAUU3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFI2MXsRUrYrhd+mb
+ZsF4bgBjWHhMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAbBgNVHSAEFDASMAYGBFUdIAAw
CAYGZ4EMAQIBMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9jcmwudXNlcnRydXN0
LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDB2Bggr
BgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNv
bS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDov
L29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAMr9hvQ5Iw0/H
ukdN+Jx4GQHcEx2Ab/zDcLRSmjEzmldS+zGea6TvVKqJjUAXaPgREHzSyrHxVYbH
7rM2kYb2OVG/Rr8PoLq0935JxCo2F57kaDl6r5ROVm+yezu/Coa9zcV3HAO4OLGi
H19+24rcRki2aArPsrW04jTkZ6k4Zgle0rj8nSg6F0AnwnJOKf0hPHzPE/uWLMUx
RP0T7dWbqWlod3zu4f+k+TY4CFM5ooQ0nBnzvg6s1SQ36yOoeNDT5++SR2RiOSLv
xvcRviKFxmZEJCaOEDKNyJOuB56DPi/Z+fVGjmO+wea03KbNIaiGCpXZLoUmGv38
sbZXQm2V0TP2ORQGgkE49Y9Y3IBbpNV9lXj9p5v//cWoaasm56ekBYdbqbe4oyAL
l6lFhd2zi+WJN44pDfwGF/Y4QA5C5BIG+3vzxhFoYt/jmPQT2BVPi7Fp2RBgvGQq
6jG35LWjOhSbJuMLe/0CjraZwTiXWTb2qHSihrZe68Zk6s+go/lunrotEbaGmAhY
LcmsJWTyXnW0OMGuf1pGg+pRyrbxmRE1a6Vqe8YAsOf4vmSyrcjC8azjUeqkk+B5
yOGBQMkKW+ESPMFgKuOXwIlCypTPRpgSabuY0MLTDXJLR27lk8QyKGOHQ+SwMj4K
00u/I5sUKUErmgQfky3xxzlIPK1aEn8=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFgTCCBGmgAwIBAgIQOXJEOvkit1HX02wQ3TE1lTANBgkqhkiG9w0BAQwFADB7
MQswCQYDVQQGEwJHQjEbMBkGA1UECAwSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHDAdTYWxmb3JkMRowGAYDVQQKDBFDb21vZG8gQ0EgTGltaXRlZDEhMB8GA1UE
AwwYQUFBIENlcnRpZmljYXRlIFNlcnZpY2VzMB4XDTE5MDMxMjAwMDAwMFoXDTI4
MTIzMTIzNTk1OVowgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5
MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO
ZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAgBJlFzYOw9sI
s9CsVw127c0n00ytUINh4qogTQktZAnczomfzD2p7PbPwdzx07HWezcoEStH2jnG
vDoZtF+mvX2do2NCtnbyqTsrkfjib9DsFiCQCT7i6HTJGLSR1GJk23+jBvGIGGqQ
Ijy8/hPwhxR79uQfjtTkUcYRZ0YIUcuGFFQ/vDP+fmyc/xadGL1RjjWmp2bIcmfb
IWax1Jt4A8BQOujM8Ny8nkz+rwWWNR9XWrf/zvk9tyy29lTdyOcSOk2uTIq3XJq0
tyA9yn8iNK5+O2hmAUTnAU5GU5szYPeUvlM3kHND8zLDU+/bqv50TmnHa4xgk97E
xwzf4TKuzJM7UXiVZ4vuPVb+DNBpDxsP8yUmazNt925H+nND5X4OpWaxKXwyhGNV
icQNwZNUMBkTrNN9N6frXTpsNVzbQdcS2qlJC9/YgIoJk2KOtWbPJYjNhLixP6Q5
D9kCnusSTJV882sFqV4Wg8y4Z+LoE53MW4LTTLPtW//e5XOsIzstAL81VXQJSdhJ
WBp/kjbmUZIO8yZ9HE0XvMnsQybQv0FfQKlERPSZ51eHnlAfV1SoPv10Yy+xUGUJ
5lhCLkMaTLTwJUdZ+gQek9QmRkpQgbLevni3/GcV4clXhB4PY9bpYrrWX1Uu6lzG
KAgEJTm4Diup8kyXHAc/DVL17e8vgg8CAwEAAaOB8jCB7zAfBgNVHSMEGDAWgBSg
EQojPpbxB+zirynvgqV/0DCktDAdBgNVHQ4EFgQUU3m/WqorSs9UgOHYm8Cd8rID
ZsswDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAG
BgRVHSAAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29t
L0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDQGCCsGAQUFBwEBBCgwJjAkBggr
BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUA
A4IBAQAYh1HcdCE9nIrgJ7cz0C7M7PDmy14R3iJvm3WOnnL+5Nb+qh+cli3vA0p+
rvSNb3I8QzvAP+u431yqqcau8vzY7qN7Q/aGNnwU4M309z/+3ri0ivCRlv79Q2R+
/czSAaF9ffgZGclCKxO/WIu6pKJmBHaIkU4MiRTOok3JMrO66BQavHHxW/BBC5gA
CiIDEOUMsfnNkjcZ7Tvx5Dq2+UUTJnWvu6rvP3t3O9LEApE9GQDTF1w52z97GA1F
zZOFli9d31kWTz9RvdVFGD/tSo7oBmF0Ixa1DVBzJ0RHfxBdiSprhTEUxOipakyA
vGp4z7h/jnZymQyd/teRCBaho1+V
-----END CERTIFICATE-----
Green is a website certificate, Red = root, Blue = special AAA intermediate certificate.
Attention! Root and intermediates may vary. Refer to actual ones from this article.
Check configuration:
apachectl -t
Reboot apache:
sudo service apache2 reload
Changes reflects immidiatelly, your SSL Certificate will be shown as trusted and valid in both modern and legacy browsers.
Before (Android 4.4)
After (Android 4.4)

My domain certificate is untrusted after the May 30th
Question:
After the 30th of May 2020, my website certificate becomes untrusted. Why and how to fix that?
Answer:
On May 30, 2020, 10:48:38 +0000 root certificate "AddTrust External CA Root" and intermediate certificate "USERTrust RSA Certification Authority" expired.
That could impact leaf certificates validation on outdated systems.
Modern browsers are not affected by the expiration since they automatically switch to the new SHA-2 root (Comodo or USERTrust).
If your service meets one of the following conditions, it may be affected:
Your application is set up to explicitly trust Addtrust External CA Root ;
Your service is using the expired Root certificate and is being accessed by applications other than browsers (e.g. API, cURL, OpenSSL, etc.) ;
Your service is using an application that has not received security updates since mid-2015 ;
Your service is using an application with broken certificate path validation (e.g. OpenSSL, OpenLDAP, Postfix) ;
If your service uses one of the affected applications regardless of the Root certificate installed, you should update the settings of the affected application.
Follow this guide to check if your service is using the expired Root:
Start OpenSSL 
openssl s_client -connect remote.host:443
where "remote.host" equals your domain name ;
If you seeAddTrust External CA RootasCN, please follow the next steps.
Otherwise, the service is not affected by the issue.
To fix any issue reinstall root and intermediate certificates bundle.
Check your "Issuer Common Name" using OpenSSL
Depending on your current vendor use following root and intermediates (updated 03.06.2020):
Product
Domain Validation
Organization Validation
Extended Validation
Comodo
root | int
root | int
root | int
Sectigo
root | int
root | int
root | int
Sectigo with AAA root
(for legacy devices)
root | int
root | int
root | int

Recent change Root Certificate from Sectigo CA (June 2025)
This documentation is to inform about a recent change made by our SSL certificate supplier Sectigo that may be causing issues with your SSL certificates.
Sectigo is currently migrating to new public root Certificate Authorities (CAs) as part of a global infrastructure upgrade. This change aims to improve longterm compatibility and security but may temporarily affect some systems that do not yet recognize the new root certificates.
What does this mean for you?
Some SSL-secured services may experience trust warnings certificate errors or unexpected behavior especially on older devices, systems, or applications that have not updated their root certificate store.
You can read more about the migration directly on Sectigo's official page:
👉 Sectigo Public Root CAs Migration
You can find additional root and intermediate certificates to install via this link:
We're on it!
Our team is actively working with Sectigo to ensure a smooth transition and to minimize any disruptions. We're also updating relevant systems and providing necessary documentation to help affected customers resolve issues as quickly as possible.
What you can do:
Ensure your servers and clients are using up-to-date operating systems and trust stores.
If you are seeing issues, add the new intermediate certificate.
Domain Validated (DV) - new_intermediate_DV.crt
Extended Validation (EV) - new_intermediate_EV.crt
Organization Validated (OV) - new_intermediate_OV.crt
Use intermediate certificate based on "Type of certificate" you have selected you have. For example, if you have a Domain Validated (DV) certificate, use new_intermediate_DV.crt.  
We appreciate your patience and understanding during this transition.

SSL Installation on Apache 2.4.9
Question:
My SSL Certificate is already active. How do I install it?
Answer:
1. Connect to your host ;
2. Turn on SSL mod:
sudo a2enmod ssl
3. Check your config path
 apachectl -S
4. Open your config, e.g. in Ubuntu path would be:
/etc/apache2/sites-enabled/000-default.conf:1
5. To set up a virtual host for HTTPS (port 443) include the following into your configuration.
Don't forget to include files to correct folders.
Save configuration.
<VirtualHost *:443>
ServerName example.com (replace with your domain)
DocumentRoot /var/www/
SSLEngine on
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
SSLCertificateChainFile /etc/ssl/certs/hosted_fun.ca-bundle
</VirtualHost>
5. Here's an explanation of directives
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem - this is a pem certificate for site itself
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key - your private key
SSLCertificateChainFile /etc/ssl/certs/hosted_fun.ca-bundle - bundle from downloaded archive (obsolete since 2.4.8, you can comment it by adding "#" before SSLCertificateChainFile or leave it but it won't affect configuration)
6. Check config syntax after you've changed configuration:
apachectl -t
7. Restart Apache service:
sudo service apache2 reload
Changes will affect immediately.

SSL Installation on MS IIS (Windows-powered systems)
Question:
How do I install SSL for Windows-powered hosts?
Answer:
Please refer to Microsoft IIS v.10 (Windows 10, Windows Server 2016) SSL Installation Guide.
Details may differ depending on your Operating System.
IIS version
System
Year
1.0
Windows NT 3.51
1995
2.0
Windows NT 4.0
1996
3.0
Service Pack 3 for Windows NT 4.0
1997
4.0
Package Option Pack for Windows NT 4.0
1998
5.0
Windows 2000
2000
5.1
Windows XP Professional
2001
6.0
Windows Server 2003
2003
7.0
Windows Vista; Windows Server 2008
2006-2008
7.5
Windows 7; Windows Server 2008 R2
2009
8.0
Windows 8; Windows Server 2012
2012
8.5
Windows 8.1; Windows Server 2012 R2
2013
10
Windows 10; Windows Server 2016
2015
SSL installation in IIS 10 requires one certificate file with the .p7b (or .cer) file extension.
Download an archive from SSLPanel first of all.
In order to install the certificate, please follow the steps below.
Upload your Certificate
Press Win + R and type “inetmgr” in the appeared window to run the Internet Information Services (IIS) Manager.
On the IIS Manager home page, locate the Server Certificates icon and double-click it.
Locate the Actions panel on the right side and click Complete Certificate Request:
In the Specify Certificate Authority Response window, perform the actions below.a) In the File name containing the certification authority’s response field, browse the file system to select your .p7b (or .cer) certificate.
b) In the Friendly name field, specify any name that will help you to identify the certificate among other files. It is best to submit the actual domain name of the certificate.
c) In the Select a certificate store for the new certificate field, leave the default value Personal.
Click OK to import the certificate to the server storage.
Once the import is completed, in the Server Certificates window, you will see a new entry associated with the imported certificate:
Bind the Certificate
Assign the certificate to your website by expanding the Sites subsection in the Connections menu on the left and select the corresponding site. Then, in the Actions panel on the right side, locate the Edit Site menu and select the Bindings option:
On the right side of the Site Bindings window, click Add:
In the Add Site Binding window, modify the fields as below:a) In the Type field, select https.b) In the IP address field, select your website’s IP address or All Unassigned.
c) In the Port field, specify 443 (default).
d) In the SSL certificate field, select the previously imported certificate, which can be identified by the friendly name.
NOTE: The Require Server Name Indication box needs to be checked if there are multiple SSL certificates on the server.
Click OK in order for the new https entry to appear in the Site Bindings window.
That’s all – the certificate should now be installed and the website should be accessible via HTTPS.

SSL Legacy devices support
Question
Is Comodo / Sectigo compatible with legacy devices like Android 4.x?
Answer
It depends on a certificate chain used.
Some prefer legacy devices. They are recommended to use the old chain.
As of 30-05-2020 such devices without a new root certificate in the list of "trusted" will show an error.
If the device detects HTTPS as non-trusted on legacy Android device, then install additional intermediate. Installation guides are here. Find additional intermediates here.
Comodo rebranded into "Sectigo" on the 01-11-2018.
Since the 14-01-2019 major part of Comodo, products changed root certificates.
Products active after 14-01-2019 use new root during activation and reissue. 
Products active before 14-01-18 use old root for activation and will use the same during reissue.
Most browsers support the Addtrust External CA root certificate, so Sectigo continues offering this root certificate. New customers are already using the Sectigo RSA CA root.
At the time of the expiration of its relevance, users already have Sectigo RSA CA root represented in the trusted root certificates, it will be used automatically.
Installing the old root will not lead to problems until 30-05-2020.
Certificates are issued for a maximum of two years.
Certificate may have a longer validity period than the root itself that you use due to "cross-signing" technique that does not cause no problems. 

Setting up OCSP for Apache server
Question
How do I set up an OCSP for server based on Apache?
Answer
Enable OCSP Stapling on Apache:
1. First check that Apache HTTPD Server 2.3.3 or above is installed by running one of the following commands:
apache2 –v
httpd -v
Versions lower than 2.3.3 do not support OCSP stapling, so you should update Apache before proceeding with the rest of this tutorial.
2. Check whether OCSP stapling is already enabled or not:
Use openssl command:
openssl s_client -connect login.live.com:443 -tls1 -tlsextdebug -status
Scroll down to "OCSP response:"
If OCSP is enabled, the “OCSP Stapling” is
OCSP Response Status: successful (0x0)
If OCSP is not enabled, you won’t see any OCSP Response Data:
OCSP response: no response sent
If it is not enabled, you won’t see any OCSP Response Data.
3. If Step 2 revealed no evidence that OCSP is enabled on your server, it is first worth checking that Apache can actually connect to our OCSP servers. Our OCSP servers are at the following locations: 
DNS HOSTNAME(S)
Destination IP
Port
OCSP.ComodoCA.com
OCSP.usertrust.com
178.255.83.1 or 2a02:1788:2fd::b2ff:5301
Tcp/80
To check connectivity, use the following telnet command:
telnet OCSP.ComodoCA.com 80
If the test is successful the reply will state ‘Connected to OCSP.ComodoCA.com’ for at least one of the ‘Destination IP’ addresses in the table above.
If the test is unsuccessful the replies will state ‘Network Unreachable’ and/or ‘Connection Timed Out’. Please make the required network changes to allow your Apache server to connect to our OCSP servers. Once complete, we advise you to re-run the test in step 2 to establish whether OCSP stapling is already enabled.
4. To enable OCSP stapling you need to edit the virtual host configuration file for your site using the editor of your choice (example editors include nano or vi):
nano /etc/apache2/sites-available/your-domain.com-ssl.conf
Make the following changes:
Add the following lines inside the <VirtualHost> tags:
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
Add a line inside the tags which points to a trusted certificate chain file. This must contain the intermediate & root certificates in order:
SSLCACertificateFile /etc/apache2/ssl/full_chain.pem
Add the following line outside the <VirtualHost> tags:
SSLStaplingCache shmcb:/var/run/ocsp(128000)
Use the example below as a reference configuration:
SSLStaplingCache shmcb: /var/run/ocsp(128000)
  <VirtualHost *:443>
      ServerAdmin admin@your-domain.com
      ServerName your-domain.com
      DocumentRoot /var/www
      SSLEngine on
      SSLUseStapling on
      SSLStaplingResponderTimeout 5
      SSLStaplingReturnResponderErrors off
      SSLCertificateFile /etc/apache2/ssl/your-domain.com/your_certificate.crt
      SSLCertificateKeyFile /etc/apache2/ssl/your-domain.com/your.key
      SSLCACertificateFile /etc/apache2/ssl/full_chain.pem
</VirtualHost>
</IfModule>
5. Test your configuration is OK:
apachectl –t
6. Restart Apache if OK:
service apache2 reload
7. Verify OCSP Stapling is working by repeating Step 2.

Setting up OCSP for MS Windows Server
Question
How do I set up an OCSP for server based on Microsoft Windows Server?
Answer
Enable OCSP Stapling on Windows Server:
1. Ensure you are using Windows Server 2008 or above.
Windows Server 2008 and above – OCSP Stapling is enabled by default. 
Versions below 2008 do not support OCSP Stapling.
Please upgrade to Windows Server 2008 or later to enable OCSP Stapling.
2.Check whether OCSP stapling is already enabled or not:
Use openssl command:
openssl s_client -connect login.live.com:443 -tls1 -tlsextdebug -status
Scroll down to "OCSP response:"
If OCSP is enabled, the “OCSP Stapling” is
OCSP Response Status: successful (0x0)
If OCSP is not enabled, you won’t see any OCSP Response Data:
OCSP response: no response sent
If you see the ‘No response sent’ message and are using Windows Server 2008 or above, then it is possible you need to (re)enable OCSP stapling. Please consult Microsoft’s documentation for help.
3. If you are still having issues, please check your Windows Server 2008+  can connect to Comodo’s OCSP servers at the following locations:
DNS HOSTNAME(S)
Destination IP
Port
OCSP.ComodoCA.com
OCSP.usertrust.com
178.255.83.1 or 2a02:1788:2fd::b2ff:5301
Tcp/80
For example, if you use telnet, use the following command:
telnet OCSP.ComodoCA.com 80
If the test is successful the reply will state ‘Connected to OCSP.ComodoCA.com’ for at least one of the ‘Destination IP’ addresses in the table above.
If the connection test is unsuccessful please make the required network changes to allow your server to connect to our OCSP servers. Once complete, we advise you to re-run the test in step 2 to establish whether OCSP stapling is now enabled.

Setting up OCSP for NGINX server
Question
How do I set up an OCSP for server-based on NGINX?
Answer
How to enable OCSP Stapling on NGINX:
1. First check that NGINX 1.3.7 or above is installed by running the following command:
nginx –v
Versions lower than 1.3.7 do not support OCSP stapling, so you should update NGINX before proceeding with the rest of this tutorial.
2. Check whether OCSP stapling is already enabled or not:
Use openssl command:
openssl s_client -connect login.live.com:443 -tls1 -tlsextdebug -status
Scroll down to "OCSP response:"
If OCSP is enabled, the “OCSP Stapling” is
OCSP Response Status: successful (0x0)
If OCSP is not enabled, you won’t see any OCSP Response Data:
OCSP response: no response sent
3. If Step 2 revealed no evidence that OCSP is enabled on your server, it is first worth checking that NGINX can actually connect to our OCSP servers. OCSP servers are at the following locations:
DNS HOSTNAME(S)
Destination IP
Port
OCSP.ComodoCA.com
OCSP.usertrust.com
178.255.83.1 or 2a02:1788:2fd::b2ff:5301
Tcp/80
To check connectivity, use the following telnet command:
telnet OCSP.ComodoCA.com 80
If the test is successful the reply will state
Connected to OCSP.ComodoCA.com
for at least one of the ‘Destination IP’ addresses in the table above.
If the test is unsuccessful the replies will state
Network Unreachable
or / and
Connection Timed Out
Please make the required network changes to allow NGINX to connect to our OCSP servers.
Once complete, re-run the test in Step 2 to establish whether OCSP stapling is already enabled.
4. To enable OCSP stapling, edit the server block configuration file for your site (or nginx.conf if server blocks are not used) using the editor of your choice (example editors include nano or vim):
nano /etc/nginx/sites-enabled/my-domain.com-ssl.conf
or
nano /etc/nginx/nginx.conf
If you need to enable OCSP stapling on just one server block, it must be the “default_server”. If you need to enable OCSP stapling on more than one server block, it must be enabled on the "default_server" before it can be enabled on any other server block. 
5. Turn on OCSP stapling and enable the server to check OCSP by adding the following lines inside 
the server block:
ssl_stapling on;
ssl_stapling_verify on;
6. Point to a trusted certificate chain file. This must contain the intermediate & root certificates in order
ssl_trusted_certificate /etc/nginx/ssl/full_chain.pem
Use the example below as a reference configuration:
server {
  listen 443 default_server;
  server_name mydomain.com
  # Change this to point to your document root.
  root /srv/www/example.com/public_html;
  index index.html index.htm;
  ssl on;
  ssl_certificate /etc/nginx/ssl/mydomain.com/my_certificate.crt;
  ssl_certificate_key /etc/nginx/ssl/mydomain.com/mydomain.key;
  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/nginx/ssl/full_chain.pem
}
7. Test your configuration is OK:
sudo service nginx configtest
OR
nginx -t
8. Restart NGINX if OK:
sudo service nginx reload
OR
systemctl restart nginx
9. Verify OCSP Stapling is working by repeating Step 2

Troubleshooting SSL installation
Sometimes it can happen that you encounter errors when installing or using your certificate. This document is an overview of the different things you can check to analyze what is wrong.
From experience we can tell that most problems arise because you did not install all root and intermediate certificates, after this a missmatch between private key and certificate is the most common issue.
Certificate is not trusted
After installing your certificate you check the website and are presented with an SSL error. The certificate is not trusted!This means that you are not presented with a full chain of trust of the certificate. Please use the full root and intermediate certificates when installing the certificate, these can be found in this knowledgebase article.
You can check your installation on this website, we use it often as it has a lot of checks that can give you plenty of information about your server's security
Or use the tool from Sectigo, when you are using a comodo certificate/
Private key and certificate do not match
When installing your certificate you are presented with a warning that the private key and the certificate do not match. This means that somewhere during the requesting of the certificate or generating the CSR and the certificate being delivered your CSR got changed. This often happens when multiple CSRs are created and people lose track of which one was eventually ordered, or if an old CSR is used that does not actually belong to the certificate.
To check if your certificate and private key belong to each other you can use this command line tool on a linux machine to see how values stack up;
openssl rsa -noout -modulus -in privateKey.key | openssl md5
 openssl req -noout -modulus -in CSR.csr | openssl md5
 openssl x509 -noout -modulus -in certificate.crt | openssl md5
From this you will get MD5 values. If they are all the same, then the files belong to each other.
If you get a missmatch, you will need to start a reissue for your certificate using a new CSR and Private key pair.

What are HSTS and the HSTS preload list?
The HSTS (HTTP Strict Transport Security) protocol is a policy / mechanism that forces a web connection over a secure HTTPS channel. In other words: without a valid SSL certificate, such a website will not load in your browser. The browser will not even show the option to ignore the SSL warning.
Implementing HSTS on your website
If you want your website always to be served over HTTPS, you can add the Strict-Transport-Security header. This HTTPS header carries a parameter max-age that defines for how long (in seconds) this requirement is valid. The optional parameter includeSubDomains can be added to enforce secure connections for all sub domains as well.
Example
An example of a HSTS header is the following:
Strict-Transport-Security: max-age=31536000; includeSubDomains
This header defines HSTS for a period of 365 days and affects sub domains as well. In other words, next time you will visit this specific website or one of its sub domains and try to do so over an unsecured HTTP connection, your browser will throw an error.
A good source of further information is Mozilla.
Limitations
Note that the HSTS header is accepted only in case the connection is already secure. The HSTS header is ignored by the browser if the page is served over an HTTP connection. For that reason, it is important that you automatically redirect every HTTP request to HTTPS.
While the HSTS header secures against man in the middle attacks (for example when browsing through public wifi access points), there is still a risk if a website is visited for the first time: at that moment a hacker can intercept your request and remove the HSTS requirement. For that reason, ensure your first visit to the website is from a secure access point.
HSTS preload list
It is possible to enforce secure connections on a higher level, even before visiting a website for the first time: the HSTS preload list. This is a list with domain names that by default support HSTS: no case-by-case HSTS headers are required, it's just always HSTS. This list is managed by Google and used by all major web browsers, including Chrome, Firefox and Internet Explorer. For those interested, a full list of domains added to the HSTS preload list is available. If you want to add your website to the HSTS preload list, check the hstspreload.org website.
Not only domains can be added to the HSTS preload list, also complete top level domains (domain extensions). If a registry decides to add its extension(s) to the HSTS preload list, every domain registered under that TLD must be served over HTTPS. The first extensions using the HSTS preload list are .bank and .insurance - two extensions that have security as their unique selling point. Google Registry has also added .app and .dev to the HSTS preload list.

What is OCSP?
Question
What is OCSP? What is the purpose of using it? 
Answer
OCSP - Online Certificate Status Protocol.
Purpose: verify the validity of the SSL certificate to be sure it's not revoked.
The encryption itself is meaningless unless additional measures are implemented, among which you can check the status of the SSL certificate. The certificate must not be revoked or expired if another - it will not be trusted.
Using OCSP browsers verifies the validity of the SSL certificate to be sure it's non-revoked.
Realized using OCSP Stapling technology (OCSP stapling).
The web server downloads a copy of the authentication center response, which is sent to the browser.
The OCSP Stapling method helps you quickly and securely check the validity of an SSL certificate. Verification sequence of the validation using OCSP Stapling technology consists of the following steps: 
Step 1. The web server hosting the SSL-protected website sends the request to the certifying center. In response from the CA, the status of the certificate comes along with a signed timestamp (timestamp). Signing a tag allows you to ensure that it will not be changed in any way by the webserver.
Step 2. The visitor's browser connects to the server. At this point, the server binds the timestamp received from the CA to the SSL certificate.
Step 3. Web browser checks the timestamp. It is signed by the certificate supplier, which means that it can be trusted.
Step 4. If the certificate is trusted, then the browser will open the page.
Otherwise, the user will receive an error message.
This approach allows you to remove the load from the certification centers and transfer it to web hosting. As a result, SSL connections are installed faster, which helps protect confidential information from users from getting into the hands of intruders.
OCSP Stapling achieves several goals:
Guarantees the security and confidentiality of user data ;
Users are more likely to download protected content because browsers do not need to make multiple requests ;
The bandwidth on the client-side is preserved, which is an advantage for mobile users ;
Increased confidence and customer satisfaction by increasing the speed of delivery of protected content ;

🇪🇸 Lista de Certificados Raíz y Certificados Intermedios
Cuando se instala un certificado SSL, también se necesita un certificado raíz y un certificado intermedio. Si no se instalan, se corre el riesgo de que los usuarios de la página web reciban un aviso del SSL porqué sus navegadores no creen en la cadena que es presentada por el servidor.
Aquí tienes una lista de los certificados raíz y los certificados intermedios.