This is basically a follow up to this question. After buying a Comodo SSL Certificate, I was also only sent two files in a zip folder - fake_domain.crt and fake_domain.ca-bundle. Most references I have seen say that I should have received 4 files, such as COMODORSADomainValidationSecureServerCA.crt.
To upload my SSL cert onto the AWS load balancer, it requires the Private Key, Public Key Certificate and Certificate Chain, all in PEM format. The private key and cert are simple enough. For the chain, using the answer from the referred question -
cat certfile.crt bundle.ca-bundle >> chain.crt
did not work. AWS responded with the following error:
Error creating certificate
Unable to validate certificate chain. The certificate chain must start with the immediate signing certificate, followed by any intermediaries in order. The index within the chain of the invalid certificate is: 1
Converting both of the files to PEM format and THEN concatenating also failed. This was the command I used and then copied the output into AWS Certificate Chain field:
openssl x509 -inform PEM -in fake_domain.crt; openssl x509 -inform PEM -in fake_domain.ca-bundle
How do I create the Certificate Chain correctly for AWS load balancers?
Certificate Chain is determined by certificate type that you buy. If you buy ssl certificate from Comodo they will send .crt and .key files which are Certificate body and Certificate Private Key.
Certificate Chain is not related with that file. You can take certificate chain file from Comodo for your ssl type. For example, if you buy ositiveSSL / EssentialSSL SHA-256 from Comodo, you need to verify your certificate with certificate chain below:
-----BEGIN CERTIFICATE-----
MIIGCDCCA/CgAwIBAgIQKy5u6tl1NmwUim7bo3yMBzANBgkqhkiG9w0BAQwFADCB
hTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNV
BAMTIkNPTU9ETyBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMjEy
MDAwMDAwWhcNMjkwMjExMjM1OTU5WjCBkDELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxNjA0BgNVBAMTLUNPTU9ETyBSU0EgRG9tYWluIFZh
bGlkYXRpb24gU2VjdXJlIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAI7CAhnhoFmk6zg1jSz9AdDTScBkxwtiBUUWOqigwAwCfx3M28Sh
bXcDow+G+eMGnD4LgYqbSRutA776S9uMIO3Vzl5ljj4Nr0zCsLdFXlIvNN5IJGS0
Qa4Al/e+Z96e0HqnU4A7fK31llVvl0cKfIWLIpeNs4TgllfQcBhglo/uLQeTnaG6
ytHNe+nEKpooIZFNb5JPJaXyejXdJtxGpdCsWTWM/06RQ1A/WZMebFEh7lgUq/51
UHg+TLAchhP6a5i84DuUHoVS3AOTJBhuyydRReZw3iVDpA3hSqXttn7IzW3uLh0n
c13cRTCAquOyQQuvvUSH2rnlG51/ruWFgqUCAwEAAaOCAWUwggFhMB8GA1UdIwQY
MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSQr2o6lFoL2JDqElZz
30O0Oija5zAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwGwYDVR0gBBQwEjAGBgRVHSAAMAgG
BmeBDAECATBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNv
bS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB
AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E
T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21v
ZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAE4rdk+SHGI2ibp3wScF9BzWRJ2p
mj6q1WZmAT7qSeaiNbz69t2Vjpk1mA42GHWx3d1Qcnyu3HeIzg/3kCDKo2cuH1Z/
e+FE6kKVxF0NAVBGFfKBiVlsit2M8RKhjTpCipj4SzR7JzsItG8kO3KdY3RYPBps
P0/HEZrIqPW1N+8QRcZs2eBelSaz662jue5/DJpmNXMyYE7l3YphLG5SEXdoltMY
dVEVABt0iN3hxzgEQyjpFv3ZBdRdRydg1vs4O2xyopT4Qhrf7W8GjEXCBgCq5Ojc
2bXhc3js9iPc0d1sjhqPpepUfJa3w/5Vjo1JXvxku88+vZbrac2/4EjxYoIQ5QxG
V/Iz2tDIY+3GH5QFlkoakdH368+PUq4NCNk+qKBR6cGHdNXJ93SrLlP7u3r7l+L4
HyaPs9Kg4DdbKDsx5Q5XLVq4rXmsXiBmGqW5prU5wfWYQ//u+aen/e7KJD2AFsQX
j4rBYKEMrltDR5FL1ZoXX/nUh8HCjLfn4g8wGTeGrODcQgPmlKidrv0PJFGUzpII
0fxQ8ANAe4hZ7Q7drNJ3gjTcBpUC2JD5Leo31Rpg0Gcg19hCC0Wvgmje3WYkN5Ap
lBlGGSW4gNfL1IYoakRwJiNiqZ+Gb7+6kHDSVneFeO/qJakXzlByjAA6quPbYzSf
+AZxAeKCINT+b72x
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFdDCCBFygAwIBAgIQJ2buVutJ846r13Ci/ITeIjANBgkqhkiG9w0BAQwFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFow
gYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYD
VQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkq
hkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkehUktIKVrGsDSTdxc9EZ3SZKzejfSNw
AHG8U9/E+ioSj0t/EFa9n3Byt2F/yUsPF6c947AEYe7/EZfH9IY+Cvo+XPmT5jR6
2RRr55yzhaCCenavcZDX7P0N+pxs+t+wgvQUfvm+xKYvT3+Zf7X8Z0NyvQwA1onr
ayzT7Y+YHBSrfuXjbvzYqOSSJNpDa2K4Vf3qwbxstovzDo2a5JtsaZn4eEgwRdWt
4Q08RWD8MpZRJ7xnw8outmvqRsfHIKCxH2XeSAi6pE6p8oNGN4Tr6MyBSENnTnIq
m1y9TBsoilwie7SrmNnu4FGDwwlGTm0+mfqVF9p8M1dBPI1R7Qu2XK8sYxrfV8g/
vOldxJuvRZnio1oktLqpVj3Pb6r/SVi+8Kj/9Lit6Tf7urj0Czr56ENCHonYhMsT
8dm74YlguIwoVqwUHZwK53Hrzw7dPamWoUi9PPevtQ0iTMARgexWO/bTouJbt7IE
IlKVgJNp6I5MZfGRAy1wdALqi2cVKWlSArvX31BqVUa/oKMoYX9w0MOiqiwhqkfO
KJwGRXa/ghgntNWutMtQ5mv0TIZxMOmm3xaG4Nj/QN370EKIf6MzOi5cHkERgWPO
GHFrK+ymircxXDpqR+DDeVnWIBqv8mqYqnK8V0rSS527EPywTEHl7R09XiidnMy/
s1Hap0flhFMCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g
JMtUGjAdBgNVHQ4EFgQUu69+Aj36pvE8hI6t7jiY7NkyMtQwDgYDVR0PAQH/BAQD
AgGGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9
MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVy
bmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggEBAGS/g/FfmoXQ
zbihKVcN6Fr30ek+8nYEbvFScLsePP9NDXRqzIGCJdPDoCpdTPW6i6FtxFQJdcfj
Jw5dhHk3QBN39bSsHNA7qxcS1u80GH4r6XnTq1dFDK8o+tDb5VCViLvfhVdpfZLY
Uspzgb8c8+a4bmYRBbMelC1/kZWSWfFMzqORcUx8Rww7Cxn2obFshj5cqsQugsv5
B5a6SE2Q8pTIqXOi6wZ7I53eovNNVZ96YUWYGGjHXkBrI/V5eu+MtWuLt29G9Hvx
PUsE2JOAWVrgQSQdso8VYFhH2+9uRv0V9dlfmrPb2LjkQLPNlzmuhbsdjrzch5vR
pu/xO28QOG8=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFs
IFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0Ux
FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9v
dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTngTlvt
H7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9
uMq/NzgtHj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzX
mk6vBbOmcZSccbNQYArHE504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LX
a0Tkx63ubUFfclpxCDezeWWkWaCUN/cALw3CknLa0Dhy2xSoRcRdKn23tNbE7qzN
E0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3CitlttNCbxWyuHv77+ldU9U0
WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTLVBowCwYD
VR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0
Jvf6xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRU
cnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx
IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcN
AQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5gdkeWxQHIzZlj7DYd7usQWxH
YINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKWt9x+Tu5w/Rw5
6wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEX
c4g/VhsxOBi0cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5a
mnkPIAou1Z5jJh5VkpTYghdae9C8x49OhgQ=
-----END CERTIFICATE-----
I've copied it from https://www.ssl2buy.com/wiki/comodo-positivessl-essentialssl-sha-2-ca-bundle. You can find appropriate certificate chain for your ssl certificate.
Related
I am facing issue at vestacp: during pass the
SSL Certificate:
-----BEGIN CERTIFICATE-----
b5XsfsteyPAX9uLwiTctWC4TO9UsnjWKx2ZBt8q4WgQ5nrmkXUwv
-----END CERTIFICATE-----
SSL Key:
-----BEGIN RSA PRIVATE KEY-----
OOTW0NwF+ENrko9JHyLGZPOrk1w/+DElPHYZWMRXB/SJIsvehu/lgMpEEGgT
-----END RSA PRIVATE KEY-----
i have already checked my certificate result this link: https://decoder.link/
it show me my certificate is valid.
You should do the following:
In the SSL Certificate field:
Paste the contents of the certificate issued to your domain. In windows you can usually verify this by simply double clicking (or opening) the .crt file. A window will pop-up with information about the certificate. Just check under "Issued to:" and make sure its issued to your domain.
In the SSL Key field
Paste the contents of the key that was created during the generation of the csr. It usually begins with -----BEGIN RSA PRIVATE KEY-----
In the SSL Certificate Authority/Intermediate
Paste the contents of the CA bundle certificate you received from your CA. That is the certificate without your domain name under "Issued to:" as explained in step 1.
Hope this helps someone. You can also read https://support.dnsimple.com/articles/what-is-ssl-certificate-chain/ to understand certificate chains.
I have an API server using a non-self signed certificate issued by a respected CA. When I connect to this server I get the following error:
x509: certificate signed by unknown authority
I connect using a golang client using the net/http library. The certificate is properly configured as I do not get an error complaining about it.
I did not expect this error because I am using a CA. I am not getting the error when using a web browser.
The problem was that I did not pass the intermediate CA certificate to the http server. The method http.ListenAndServeTLS requires the intermediate CA certificate in the same certificate file.
The fix was easy, just add the intermediate certificate of your CA in your certificate file:
-----BEGIN CERTIFICATE-----
<YOUR OWN CERTIFICATE>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<INTERMEDIATE CA CERTIFICATE>
-----END CERTIFICATE-----
We have a password-protected pfx file, expiring in a few days, which we use to sign our exes.
We have renewed our SSL certificate from Symantec, but all we have received is a bunch of data:
Below is your Code Signing certificate:
-----BEGIN CERTIFICATE-----
base-64 encoded data
-----END CERTIFICATE-----
Below is the intermediate CA certificate:
-----BEGIN CERTIFICATE-----
base-64 encoded data
-----END CERTIFICATE-----
Below is your certificate in pkcs7 format:
-----BEGIN CERTIFICATE-----
base-64 encoded data
-----END CERTIFICATE-----
I have seen a few tutorials to create pfx files from .cer and .key files, but the fun part is, Symantec doesn't use the same terminology as the rest of the world. So I don't know which is which. And no single tutorial explains what should be in the files, so I can't go from there either. So, I don't know how to create the .key file, for instance.
Thanks!
It turns out that the main requirement is to install the certificate on a browser, from the computer that has made the request for a new certificate.
Then, most browsers (IE, FF, Chrome) can export it to PFX from the installed certificates list.
More info can be found here:
http://blog.ksoftware.net/2011/07/exporting-your-code-signing-certificate-to-a-pfx-file/
http://blog.ksoftware.net/2011/07/exporting-your-code-signing-certificate-to-a-pfx-file-from-firefox/
https://knowledge.verisign.com.sg/support/code-signing-support/index?page=content&id=AR190&actp=search&viewlocale=en_US&searchid=1360582675798
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have an e commerce site naturalvape.us using wordpress. hostgator is where its hosted.
I have a ssl certification installed. My issue my site shows a caution sign and says it is unsecured. The guys at hostgator gave me a link to this site to force ssl/https. Apparently some type of code is needed to redirect to the secure site.
Why do I have a warning in the browser?
How can I redirect the site to https?
To expand upon Boan's comment, you certificate chain is malformed.
You are only sending the end entity (server) certificate; and you need to send both the end entity certificate and two intermediate certificates required for Comodo.
You need to send the intermediate certificates to avoid the "which directory" problem. Its a well known problem in PKI. That's what clients are experiencing - they don't know where to go to get the missing intermediate certificate.
Here's how you can check for it:
$ openssl s_client -connect naturalvape.us:443 -showcerts
CONNECTED(00000003)
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = naturalvape.us
verify error:num=20:unable to get local issuer certificate
verify return:1
...
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=naturalvape.us
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
-----BEGIN CERTIFICATE-----
MIIFUDCCBDigAwIBAgIRAOIeCA8uCx0hLc8AQSHiak8wDQYJKoZIhvcNAQELBQAw
gZAxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
...
t3d8prtVxlUd9xp0AEXPOLI1uKQlDKNCOQlHFrINkZbwwg6hmomiFXx5IpfVSb9U
XIqr/cZP7xtD2oiYCJ2giJ7dHLU=
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=naturalvape.us
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
---
...
Notice there's one certificate present with a subject of CN=naturalvape.us (subject is the "s:" in the display). The issuer is CN=COMODO RSA Domain Validation Secure Server CA, but that intermediate certificate is missing (issuer is the "i:" part in the display).
To fix this, you need to fetch COMODO RSA Domain Validation Secure Server CA from [Intermediate #2 (SHA-2)] Comodo RSA Domain Validation Secure Server CA.
The intermediate certificate is already PEM encoded. Take your server certificate, and append the COMODO RSA Domain Validation Secure Server CA intermediate. That means there will be two certificates in the file. They will look like:
-----BEGIN CERTIFICATE-----
<server certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<intermediate certificate>
-----END CERTIFICATE-----
Plug that into your site under the server certificate.
Unfortunately, its not enough to add just COMODO RSA Domain Validation Secure Server CA. You also need to add COMODO RSA Certification Authority. Its another missing intermediate certificate. You can get COMODO RSA Certification Authority from [Intermediate #1 (SHA-2)] COMODO RSA Certification Authority.
So they will look like:
-----BEGIN CERTIFICATE-----
<end entity/server certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<intermediate certificate #2>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<intermediate certificate #1>
-----END CERTIFICATE-----
Users (relying parties) will still need to have/trust the issuer of the last missing intermediate (the last missing intermediate is COMODO RSA Domain Validation Secure Server CA). The issuer of the last missing intermediate is CN=AddTrust External CA Root, and it should be built-in to the browser or one of those cacerts.pem packs.
Once you concatenate the two missing intermediates certificates with the server certificate (and upload it), you can test as follows.
First, download the trust anchor. Its CN=AddTrust External CA Root, and it can be found at [KMCS] AddTrust External CA Root.
Second, run openssl s_client to verify. Notice the addition of the CAfile option and the "Verify result OK (0)".
$ openssl s_client -connect naturalvape.us:443 -CAfile addtrustexternalcaroot_kmod.crt
CONNECTED(00000003)
...
Start Time: 1407558078
Timeout : 300 (sec)
Verify return code: 0 (OK)
Your images are loading through http. Go to your wordpress settings, and change both the site urls so they start with 'https'.
http://userguide.expand2web.com/wp-content/forum-image-uploads/don/wordpress-site-url.jpg
I have received a p7b file from a bank which should be a signed certificate, as a response to a csr file that I have sent.
I have manged to extract a pem certificate with the following command:
openssl pkcs7 -print_certs -in certificate.p7b -out certificate.crt
The certificate.crt file that I extracted has the following structure:
subject=/C=MK/ST=// ......
issuer=/CN=XXX
-----BEGIN CERTIFICATE-----
.
.
.
-----END CERTIFICATE-----
subject=/CN=XXX
issuer=/CN=XXX
-----BEGIN CERTIFICATE-----
.
.
.
-----END CERTIFICATE-----
I am not an expert on SSL, but I assume that this is a certificate chain, since it has two certificates.
I have configured apache with the following directives:
SSLEngine on
SSLCertificateFile path/to/certs/certificate.crt
SSLCertificateChainFile path/to/certs/certificate.crt
SSLCertificateKeyFile path/to/certs/private.key
Apache serves this properly on https, but the browser does not recognize this as a signed certificate, and gives me that Untrusted connection screen.
Am I doing something wrong, or the certificate is not signed by a trusted authority... Is there a way to check if the certificate is signed properly?
You may use the SSL configuration checker if the certificate was installed properly, refer to the link below:
http://www.sslshopper.com/ssl-checker.html
or
https://sslcheck.globalsign.com/en_US
You may also use this link to check who issued the certificate and details of the certificate:
http://www.sslshopper.com/certificate-decoder.html