Self-Signed certificate: openssl 21 (unable to verify the first certificate) [duplicate] - go

I have two extremely similar self signed certificates, generated via two different methods.
To test them I have:
Added an entry in my hosts file for local.mydomain.com
Set up an nginx server to listen on that domain on port 443 with the certificate under test plus associated private key (I then switch the cert and restart nginx to compare)
Connected to nginx with openssl s_client -connect local.mydomain.com -CAfile /path/to/the/ca/cert.pem
One certificate fails:
CONNECTED(00000003)
depth=0 CN = local.mydomain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = local.mydomain.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=local.mydomain.com
i:/CN=local.mydomain.com
---
One certificate succeeds:
CONNECTED(00000003)
depth=0 CN = local.mydomain.com
verify return:1
---
Certificate chain
0 s:/CN = local.mydomain.com
i:/CN = local.mydomain.com
---
I compare the details of the certificates with openssl x509 -in /path/to/the/ca/cert.pem -text -noout
The failing cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
47:dc:02:c7:11:fc:8e:96:45:22:aa:6b:23:79:32:ca
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=local.mydomain.com
Validity
Not Before: Nov 18 11:55:31 2016 GMT
Not After : Nov 18 12:15:31 2017 GMT
Subject: CN=local.mydomain.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<stuff>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:local.mydomain.com
X509v3 Subject Key Identifier:
6D:4F:AF:E4:60:23:72:E5:83:27:91:7D:1D:5F:E9:7C:D9:B6:00:2A
Signature Algorithm: sha256WithRSAEncryption
<stuff>
The working cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
9b:6b:3d:a3:b9:a3:a4:b4
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=local.mydomain.com
Validity
Not Before: Nov 19 13:27:30 2016 GMT
Not After : Nov 19 13:27:30 2017 GMT
Subject: CN=local.mydomain.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<stuff>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
03:E7:DA:AA:2E:CC:23:ED:C5:07:3D:E1:33:86:F5:22:D4:76:EB:CB
X509v3 Authority Key Identifier:
keyid:03:E7:DA:AA:2E:CC:23:ED:C5:07:3D:E1:33:86:F5:22:D4:76:EB:CB
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
57<stuff>
Looking at this the most obvious difference is that the working cert has CA:TRUE under X509v3 Basic Constraints. However, from reading around the web I was under the impression that self signed certs weren't meant to be CAs, in particular this says they normally won't be:
https://security.stackexchange.com/questions/44340/basic-self-signed-certificate-questions
The answer there says that being self-signed there is no CA involved. But maybe openssl requires self signed certs to have that set anyway?

From my own experiments I can confirm what you see. My explanation of the behavior is that a self signed certificate is still a certificate which is signed by the issuer, even if the issuer's certificate is the certificate itself. But only CA certificates can be used to sign certificates, i.e. that's exactly the constraint CA:true allows. This means that a self-signed certificate needs also to be a CA certificate with the constraint CA:true.

RFC5280 says:
So, if your certificate does not have CA:TRUE flag, this certificate may not be used to verify the signature on any certificate, including itself. OpenSSL correctly follows the RFC.
It is incorrect to think that a certificate belongs to one of two types, either "CA certificate" or "end-entity certificate". A certificate with CA:TRUE can be used for authenticating the entity. This is exactly what you do when you authenticate with a self-signed certificate. It can also be a certificate with CA:TRUE, signed by someone else.

Related

My self-signed APK got Blocked by Play Protect

I am a home user working on Windows 7 X64. I have a problem with my signed APK.
My app is only for home use and learning. I won't submit to Google Play.
When installed, it shows
Blocked by Play Protect.
Play Protect doesn't recognise this app's developer.
Apps from unknown developers can sometimes be unsafe.
Tools:
keytool.exe v8.0.3019.9
openssl.exe v1.1.1k
zipalign.exe v29.0.3
apksigner.jar v29.0.3
Batch Script:
cls
del /f KEY.JKS
del /f KEY.PEM
del /f KEY.PK8
del /f CERT.PEM
"C:\Program Files\Java\jre1.8.0_301\bin\keytool.exe" -genkeypair -v -alias MYKEY -storepass 123456 -keypass 123456 -keystore KEY.JKS -keyalg RSA -keysize 2048 -validity 9999 -dname "EMAILADDRESS=android#android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US"
openssl.exe req -x509 -nodes -days 9999 -newkey rsa:2048 -keyout KEY.PEM -out CERT.PEM -subj "/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android#android.com" -config openssl.cnf
openssl.exe pkcs8 -topk8 -nocrypt -inform PEM -outform DER -in KEY.PEM -out KEY.PK8
zipalign.exe -f -p 4 myApp.apk myApp_Align.apk
rem java -jar apksigner.jar sign --ks KEY.JKS --ks-pass pass:123456 --out myApp_Signed.apk myApp_Align.apk
java -jar apksigner.jar sign --key KEY.PK8 --cert CERT.PEM --out myApp_Signed.apk myApp_Align.apk
java -jar apksigner.jar verify -v --print-certs myApp_Signed.apk
pause
My key got blocked:
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Number of signers: 1
Signer #1 certificate DN: EMAILADDRESS=android#android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
Signer #1 certificate SHA-256 digest: 07d51277869be18dfe8618d797ad1c0c8e16b7c067d9d224962af960c0382bfb
Signer #1 certificate SHA-1 digest: 85789690f7f12d0d6f4c7f67adb96429c326049f
Signer #1 certificate MD5 digest: 13b9633388142f4d40295cd45ac65aa9
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: bb280251b6eb2a1dd5e2493a3ac23881e254274318a2247bce84fd067181c441
Signer #1 public key SHA-1 digest: b2be0f31d13ce91162bf7ccf9fa4662e7c47b2d6
Signer #1 public key MD5 digest: 9648bca600a81a383cffd490a8614852
I downloaded some APK from the internet and it doesn't get blocked.
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Number of signers: 1
Signer #1 certificate DN: EMAILADDRESS=android#android.com, CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US
Signer #1 certificate SHA-256 digest: a40da80a59d170caa950cf15c18c454d47a39b26989d8b640ecd745ba71bf5dc
Signer #1 certificate SHA-1 digest: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81
Signer #1 certificate MD5 digest: e89b158e4bcf988ebd09eb83f5378e87
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 2048
Signer #1 public key SHA-256 digest: ef57b690165cb561b5026922c00d2d6574e8b184fa7d161e076f06e06e6d35db
Signer #1 public key SHA-1 digest: 0c2440c055c753a8f0493b4e602d3ea0096b1023
Signer #1 public key MD5 digest: 452f8cfe026b30a8a3e99a6074e5f285
I downloaded KEY.PK8 and CERT.PEM from the internet and it doesn't get blocked.
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Number of signers: 1
Signer #1 certificate DN: EMAILADDRESS=lorenz#londatiga.net, CN=Lorensius W. L. T, OU=AndroidDev, O=Londatiga, L=Bandung, ST=Jawa Barat, C=ID
Signer #1 certificate SHA-256 digest: 518ac8bdaf0c767deb31bae1eba826adbef793a68f22784cf3e19c67ba87ecb9
Signer #1 certificate SHA-1 digest: ece521e38c5e9cbea53503eaef1a6ddd204583fa
Signer #1 certificate MD5 digest: eea6f6f40858b8215c48b0465fe479b8
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 1024
Signer #1 public key SHA-256 digest: d8dc2ef9b37fcb543b07678a2d64d3a1dc5122642ee824a61dfbed0bf86d25c4
Signer #1 public key SHA-1 digest: 74bd7b456d9e651fc84446f65041bef1207c408d
Signer #1 public key MD5 digest: 58d291bc49e568eb8fc84dabaf508d08
What's wrong with my steps? I switched to keystore (KEY.JKS), it didn't work too.
Unless google knows your key's fingerprint or the APK itself is signed with a google key, it gets flagged by play protect as "unknown developer". You can "verify" your key by submitting an application signed by that particular key on google play

How to check two sided secured https connection using OpenSSL / Curl

The question seems to be asked before:
OpenSSL Verify return code: 20 (unable to get local issuer certificate). However the difference is that it is about a local issuer certificate. Besides, the answers are not for a Windows computer.
Problem description
On a windows computer, I've got a program that tries to contact a secure server. The security is with certificates on both sides.
Problem: I can't contact it, so I tried to find out if the certificates are correctly installed
Searches, a.o. here on stack overflow, indicated that a good method to find problems would be to use OpenSsl for this, even though I'm running a windows computer.
As an example to check if all certificates for a connection are correctly installed, I was advised to check the connection with google.com:
openssl.exe s_client -connect google.com:443
(My browsers have no problems connecting to this server)
The first lines of the response are
CONNECTED(00000184)
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=*.google.com
i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
...
And further down the same error twice:
Verification error: unable to get local issuer certificate
Verify return code: 20 (unable to get local issuer certificate)
Alas the OpenSSL documentation about s_client isn't very informative about these errors.
So what does it mean? Am I missing some certificates to communicate with google.com, or am I using the incorrect program for this?
Of course google.com is just an example. I chose this, so I could check if reported problems are because of certificate problems, or because of the command I use.
For my actual server that I try to contact, I have the proper certificates (up to the root) as .CER files. The root certificate is in the winstore.
Patrick Mevzek pointed me towards the proper answer (Thanks Patrick!). Because some investigation was needed, I decided to write it down as a complete answer.
I'm working in Windows Server 2012. Newer versions will probably work similarly. To test the certificates and the communication I use:
openssl for windows. Find a compiled version here
curl for window here
Files:
So I am a Client of a Server. There is a two-way secure certification: via very secure methods we have the following files:
A Root certificate that can be trusted: Root.Pem
A chain of untrusted certificates issued by the Root certificate: A.Pem, B.Pem, C.Pem
A private key file MyPrivate.key and a trusted certificate issued by C.Pemto ensure my identity: MyCertificate.pem
If needed, Convert certificate file to PEM format
If the certificates are not in PEM format, we need to convert them first. To check if they are in PEM, open them in a text editor. A PEM file looks like:
-----BEGIN CERTIFICATE-----
MIIFyjCCA7KgAwIBAgIEAJiWjDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJO
...
-----END CERTIFICATE-----
If it is not, we can use openSSL to convert the file:
openssl.exe x509 -inform DER -in myCertificate.cer -out myCertificate.Pem
inform: the format of the input file: DER / NET / PEM (well, if already PEM you won't have to convert)
in / out: the input file, the output file
Verify the certificate chain
For extra security, I verified every certificate separately. It is probably also safe to do this in one step.
Check validity of the root certificate. For instance by checking the fingerprint with a published fingerprint.
Check validity of the untrusted certificates
(1) Is A.pem issued by Root.Pem?
openssl.exe verify -show_chain -CAfile root.pem A.pem
Parameter -CAfile contains the trusted certificate. The last file is the file that contains the certificate to be verified.
Reply should be similar to:
A.pem: OK
Chain:
depth=0: C = NL, ..., CN = <some text describing certificate A> (untrusted)
depth=1: C = NL, ..., CN = <some text describing the trusted root certificate>
(2) Is B.Pem issued by the trusted A.Pem?
Now that A.pem can be trusted, we can check B.Pem. For this we mention the intermediate certificate A.Pem as untrusted as advised in this answer
openssl.exe verify -show_chain -CAfile root.pem -untrusted A.pem B.pem
Reply:
B.pem: OK
Chain:
depth=0: C = NL, ..., CN = <some text describing certificate B> (untrusted)
depth=1: C = NL, ..., CN = <some text describing certificate A> (untrusted)
depth=2: C = NL, ..., CN = <some text describing the trusted root certificate>
(3) Can we trust the rest of the certificate chain?
So now B can be trusted. To continue checking the chain, concatenate the untrusted CA-files into one untrusted.pem file. Do not add MyCertificate.Pem
-----BEGIN CERTIFICATE-----
MIIGNjCCBB6gAwIBA...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
jCCBB6gAwIBA34F..
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
dZBo31cAYsByRL...
-----END CERTIFICATE-----
And the command:
openssl.exe verify -show_chain -CAfile root.pem -untrusted untrusted.pem myCertificate.pem
Reply:
MyCertificate.pem: OK
Chain:
depth=0: C = NL, ..., CN = <some text describing MyCertificate> (untrusted)
depth=1: C = NL, ..., CN = <some text describing certificate C> (untrusted)
depth=2: C = NL, ..., CN = <some text describing certificate B> (untrusted)
depth=3: C = NL, ..., CN = <some text describing certificate A> (untrusted)
depth=4: C = NL, ..., CN = <some text describing the trusted root certificate>
I guess maybe all those intermediate steps were not necessary to check the validity.
Check Connection
Now that the certificate chain is trusted, we can use OpenSsl to check the connection.
Concatenate all certificates, except MyCertificate.pem in one file AllTrusted.pem, use a text editor, or a command Copy Root.Pem + A.Pem + B.Pem ... Trusted.Pem
Command:
openssl.exe s_client CAfile Trusted.Pem -connect google.nl:443
Replace google.nl:443 with the proper address and port
Reply, something similar to:
CONNECTED(00000124)
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=google.com
i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIhWDCCIECgAwIBAgIQaEMB4EOx3++GhdWADJfgEjANBgkqhkiG9w0BAQsFADBU
...
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=google.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
The server sent a certificate to identify itself. The client should use this certificate and its trusted CA-chain to check the identity of the server.
To continue communicating, we need a PEM file that contains the mentioned issuer and its issuers until the root. Use the procedure described above to get a complete certificate chain, and add all certificates in the correct order to a file trusted.pem. If you copy-paste the received certificate to a PEM file (text), you should be able to verify this received certificate the same way as I verified MyCertificate.Pem as described above.
Once the CA certificates for the received certificates were installed, my openssl s_client command replied with:
...
SSL handshake has read 8945 by
Verification: OK
---
New, TLSv1.2, Cipher is ...
Server public key is 2048 bit
Start Time: 1551779993
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
So the certificate chain to identify the server is accepted.
Idintify me to the server
The next step will be to check if I can identify myself at the server using MyCertficate.pem.
This is the first time I need my private key file. We'll use curl for this:
Command:
curl.exe -v --cacert trusted.pem --cert MyCertificate.pem --key MyPrivate.key https://...
-v: verbose
--cacert: the text file with the concatenation of the trusted CA chain until the root, as verified using openssl verify
--Cert: the certificate to be used by me to identify myself
--Key: the private key for this certificate
Reply:
...
* successfully set certificate verify locations:
* CAfile: trustall.pem
...
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
...
* Server certificate:
* subject: C=NL; ...
* start date: Apr 19 12:10:31 2016 GMT
* expire date: Apr 19 12:10:31 2019 GMT
...
* issuer: C=NL; O= <description of certificate issuer; should be in trusted.pem>
* SSL certificate verify ok.
> GET /exchange/ciot HTTP/1.1
> Host: ....
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 400 Bad Request
What we see:
TrustAll.Pem contains the trusted certificates
(Out) Client Hello - (In) Server Hello: apparently we are on speaking terms
Server sends certificate and requests one
Client sends its certificate to identify itself
Display of the received certificate, the one with which the server identifies itself. The issuer is expected to be in trusted.pem
The received certificate is verifies and accepted. Data transfer can start
Because I didn't send any data, the response is a 400 Bad Request
So this is enough to know that both client and server use trusted certificates and that communication is possible

Generating a certificate chain in Ansible

I am trying to generate a chain (self signed + one signed by the self signed) of certificates using Ansible OpenSSL modules.
So far have the following tasks:
- name: Generate a Self Signed OpenSSL certificate
become: yes
block:
- apt:
name: python-openssl
update_cache: yes
- openssl_privatekey:
path: /tmp/ansible.com.pem
- openssl_csr:
path: /tmp/ansible.com.csr
privatekey_path: /tmp/ansible.com.pem
common_name: ansible.com
- openssl_certificate:
path: /tmp/ansible.com.crt
privatekey_path: /tmp/ansible.com.pem
csr_path: /tmp/ansible.com.csr
provider: selfsigned
- openssl_privatekey:
path: /tmp/child.com.pem
- openssl_csr:
path: /tmp/child.com.csr
privatekey_path: /tmp/child.com.pem
common_name: child.com
- openssl_certificate:
path: /tmp/child.com.crt
privatekey_path: /tmp/ansible.com.pem
csr_path: /tmp/child.com.csr
provider: selfsigned
But the problem is that child certificate is not valid:
openssl verify -verbose -CAfile /tmp/ansible.com.crt /tmp/child.com.crt
/tmp/child.com.crt: CN = child.com
error 18 at 0 depth lookup:self signed certificate
OK
I am using Ansible 2.6.1
A self-signed certificate is a self-signed certificate regardless of what key you provided for signing (this key is never verified anyway, because "you trust the certificate directly").
If you check the contents of the child.com.crt certificate with openssl x509 -in /tmp/child.com.crt -text -noout command, you'll see:
Certificate:
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=child.com
Subject: CN=child.com
not Issuer: CN=ansible.com (and there is no way to know whose key it is during the signing task, based on the key alone ― a key is just a random number; you'd need to provide the certificate of the signing party somewhere in the task, which you don't).
What you want to achieve will be possible in Ansible 2.7 with a new provider ownca introduced by this commit:
The 'ownca' provider is intended for generate OpenSSL certificate signed with your own CA (Certificate Authority) certificate (self-signed certificate).
[ ]
Example:
- name: Generate an OpenSSL certificate signed with your own CA certificate
openssl_certificate:
path: /etc/ssl/crt/ansible.com.crt
csr_path: /etc/ssl/csr/ansible.com.csr
ownca_path: /etc/ssl/crt/ansible_CA.crt
ownca_privatekey_path: /etc/ssl/private/ansible_CA.pem
provider: ownca
For now (up to Ansible 2.6.x) you need to call openssl x509 -req (see examples) with the command module.

Docker for Mac: x509: certificate signed by unknown authority error

I am using the latest Docker on Mac (native) and just try to do this:
docker run -d -p 8888:8888 jupyter/all-spark-notebook
But I got below error:
Unable to find image 'jupyter/all-spark-notebook:latest' locally
latest: Pulling from jupyter/all-spark-notebook
fdd5d7827f33: Pull complete
a3ed95caeb02: Pull complete
f08e494cf5cc: Pull complete
6548f4aff175: Downloading
d762b5abb43e: Download complete
c841d1ad6a8e: Download complete
78ff99539390: Download complete
99dfa5547e73: Download complete
408ccccf138d: Download complete
0f7e4eccd74d: Download complete
9177afc586c3: Download complete
b474b13b1b14: Download complete
f204d6cd4f55: Downloading
a8a42c20abb9: Download complete
9ac0b73ff157: Downloading
0553d92e0f21: Downloading
dfaa7db17378: Download complete
262fc767b542: Download complete
a21800239eaa: Download complete
afe6294b97d7: Download complete
3d4589d060ea: Download complete
b81971b6c8e4: Download complete
9daebe0247b8: Downloading
ce63d084a226: Downloading
73eb272114bc: Download complete
b2c0c287ae3a: Download complete
f306272598a0: Downloading
04882c9afb9d: Downloading
docker: x509: certificate signed by unknown authority.
See 'docker run --help'.
I am doing this inside company VPN so it's behind firewall / proxy. If I get out of VPN to pull image and then get back in VPN to run, it's fine.
However, I do need to fix this problem because I do work inside the company a lot and cannot disconnect VPN at work. I have tried Google and found many Github issues like this https://github.com/docker/docker/issues/6474 but none solved the problem. I have tried docker run -d -p 8888:8888 jupyter/all-spark-notebook --insecure-registry https://index.docker.io:8888 and it didn't work either.
Below are some outputs based on what people were checking:
openssl s_client -connect index.docker.io:443 output this:
CONNECTED(00000003)
depth=1 /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/OU=GT98568428/OU=See www.rapidssl.com/resources/cps (c)15/OU=Domain Control Validated - RapidSSL(R)/CN=*.docker.io
i:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
1 s:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEpDCCA4ygAwIBAgIDAyF3MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlVT
...
YMYqJP5MkuAKzDL5u0b8mD/EHtoPkfWOIsA5i9YrAAoWRVOJHwfFfgSY+EpXpFc4
AZUPmdZGh6q1YNavRoOL/1D5aP/VBBtofj54uMbKOK8q6vxIXSyzaw==
-----END CERTIFICATE-----
subject=/OU=GT98568428/OU=See www.rapidssl.com/resources/cps (c)15/OU=Domain Control Validated - RapidSSL(R)/CN=*.docker.io
issuer=/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 2429 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
Session-ID: F2A7D08F3628FFC3334DBFF7698E05CC5027A61F4F88914E541F466FD6004702
Session-ID-ctx:
Master-Key: 1EF9EB10A666597135CA6D5F14F10C717483C4C3873288281D0156410FE93C232E494A0935AA416EA736AE8CBDFBD925
Key-Arg : None
Start Time: 1462855143
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
HTTP/1.0 408 Request Time-out
Cache-Control: no-cache
Connection: close
Content-Type: text/html
<html><body><h1>408 Request Time-out</h1>
Your browser didn't send a complete request in time.
</body></html>
closed
And openssl s_client -showcerts -verify 32 -CApath . -connect index.docker.io:443 output this:
verify depth is 32
CONNECTED(00000003)
depth=1 /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
verify error:num=27:certificate not trusted
verify return:1
depth=0 /OU=GT98568428/OU=See www.rapidssl.com/resources/cps (c)15/OU=Domain Control Validated - RapidSSL(R)/CN=*.docker.io
verify return:1
---
Certificate chain
0 s:/OU=GT98568428/OU=See www.rapidssl.com/resources/cps (c)15/OU=Domain Control Validated - RapidSSL(R)/CN=*.docker.io
i:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
-----BEGIN CERTIFICATE-----
MIIEpDCCA4ygAwIBAgIDAyF3MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlVT
...
YMYqJP5MkuAKzDL5u0b8mD/EHtoPkfWOIsA5i9YrAAoWRVOJHwfFfgSY+EpXpFc4
AZUPmdZGh6q1YNavRoOL/1D5aP/VBBtofj54uMbKOK8q6vxIXSyzaw==
-----END CERTIFICATE-----
1 s:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----BEGIN CERTIFICATE-----
MIIEJTCCAw2gAwIBAgIDAjp3MA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT
...
ZI3NjGFVkP46yl0lD/gdo0p0Vk8aVUBwdSWmMy66S6VdU5oNMOGNX2Esr8zvsJmh
gP8L8mJMcCaY
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=GT98568428/OU=See www.rapidssl.com/resources/cps (c)15/OU=Domain Control Validated - RapidSSL(R)/CN=*.docker.io
issuer=/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 2429 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
Session-ID: 04E8384F625F401B53C8ACA4D1F68A4EC300C0039ABE6C4117DE97C721B58DB2
Session-ID-ctx:
Master-Key: F08AD33B9D234A31DB7A9940A1CA6C4EC1FD780871F117780108E7F39909487B647FEBC5643BF1F2ADC5377407968D8C
Key-Arg : None
Start Time: 1462857210
Timeout : 300 (sec)
Verify return code: 27 (certificate not trusted)
---
^C
Could someone help me figure out a solution without disconnect from VPN to pull image and get back in to run each time?

OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed) while connecting to Paypal

I know there are lots of discussion regarding this error but sorry to say that I'm unable to find any working solution over there.
I'm developing a ecommerce site using ShareTribe.I'm trying to implement Paypal as payment gateway.So I'm using Activemerchant.
Everything works fine on development machine but when I deploy my rails app to production It throws
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed)
I'm initializing my Activemerchant as
config.after_initialize do
ActiveMerchant::Billing::Base.mode = :test
paypal_options = {
login: "bla bla",
password: "bla bla",
signature: "bla bla",
appid: "APP-80W284485P519543T"
}
::EXPRESS_GATEWAY = ActiveMerchant::Billing::PaypalExpressGateway.new(paypal_options)
end
Added HTTPS and Disabled SSLV3
After lots of googling I found that
SSLv3 was proven to be insecure with the POODLE vulnerability. You
should make sure that your system has the latest version of OpenSSL so
that you can use TLSv1.2.
So I disabled SSLV3 as shown below
openssl s_client -connect kickmarket.eu:443
CONNECTED(00000003)
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.kickmarket.eu
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.kickmarket.eu
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.kickmarket.eu
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=www.kickmarket.eu
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
Server certificate
-----BEGIN CERTIFICATE-----
...........................................
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=www.kickmarket.eu
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
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 2038 bytes and written 375 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 4D23F4A942AAD4264BE96EB5F1E62204269D882A64ACFBD2D139CD2F10A449A0
Session-ID-ctx:
Master-Key: 1E381DAA3BA90FE3609606716E7E9A2EB2E2F671E9F3C4005D8EBAE009103A7AB771FB2AC8B45F169F43CBD0AD352E06
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
..................................
Start Time: 1446132175
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
But after restarting nginx I got the same problem.Is there Any way to fix this issue.
Any suggestion will be appreciated.
This is most likely due to the upgrade to SHA256 certification. Please review the following documentation:
https://devblog.paypal.com/paypal-ssl-certificate-changes/
The primary cause for this is the rvm installed ruby does look into the wrong directory for certificates whereas the OSX-ruby will look into the correct one.
What you wanna do is NOT TO USE any of the precompiled rubies and rather have ruby compiled on your local machine, like so:
rvm install 2.2.0 --disable-binary
You can read detailed explanation https://toadle.me/2015/04/16/fixing-failing-ssl-verification-with-rvm.html

Resources