Getting a self-signed certificate error with ProtonBridge and mbsync - self-signed-certificate

I am attempting to setup isync with ProtonBridge and getting the following error:
SSL error connecting 127.0.0.1 (127.0.0.1:1143): self signed certificate
I am aware that this is the localhost, as such the certificate that we provide is self-signed. In any other email client, in Thunderbird for instance, it is a matter of confirming a security exception for port 1143 on 127.0.0.1. as detailed in step 5 here. What I quite did not figure out is how to do that in mbsync. Here is my .msyncrc:
IMAPStore someuser-remote
Host 127.0.0.1
Port 1143
User info#someuser.net
Pass protonbridgepassword
SSLType STARTTLS
CertificateFile /etc/ssl/certs/ca-certificates.crt
MaildirStore user-local
Path ~/Mail/
Inbox ~/Mail/INBOX
Subfolders Verbatim
Flatten .
Channel user
Master :user-remote:
Slave :user-local:
Create Both
Expunge Both
Patterns *
SyncState *
Tried with option SystemCertificates no to no avail as well. Here is the full log:
Reading configuration file /home/user/.mbsyncrc
C: 0/1 B: 0/0 M: +0/0 *0/0 #0/0 S: +0/0 *0/0 #0/0
Channel user
Opening master store user-remote...
Resolving 127.0.0.1... ok
Connecting to 127.0.0.1 (127.0.0.1:1143)...
Opening slave store user-local...
SSL error connecting 127.0.0.1 (127.0.0.1:1143): self signed certificate
C: 1/1 B: 0/0 M: +0/0 *0/0 #0/0 S: +0/0 *0/0 #0/0

As mentioned on the comment above by #pusillanimous, I confirm that pointing directly to the cert at the protomail bridge works.
So you simply need to to add the following to your .mbsyncrc
CertificateFile ~/.config/protonmail/bridge/cert.pem

You need to copy ProtonBridge's certificate as explained here in Step #1: Get the certificates. The openssl command is somewhat different though, as you need to specify the STARTTLS protocol when connecting to the local server:
openssl s_client -starttls imap -connect 127.0.0.1:1143 -showcerts
It should give you something along these lines:
CONNECTED(00000003)
depth=0 C = CH, O = Proton Technologies AG, OU = ProtonMail, CN = 127.0.0.1
verify error:num=18:self signed certificate
verify return:1
depth=0 C = CH, O = Proton Technologies AG, OU = ProtonMail, CN = 127.0.0.1
verify return:1
---
Certificate chain
0 s:/C=CH/O=Proton Technologies AG/OU=ProtonMail/CN=127.0.0.1
i:/C=CH/O=Proton Technologies AG/OU=ProtonMail/CN=127.0.0.1
-----BEGIN CERTIFICATE-----
MIIDizCCAnOgAwIBAgIQBW7/mrcQcB5Iu1POkJ3YNzANBgkqhkiG9w0BAQsFADBX
MQswCQYDVQQGEwJDSDEfMB0GA1UEChMWUHJvdG9uIFRlY2hub2xvZ2llcyBBRzET
(...)
kNvCZidKp31PdIO9IzQn2cI86f2mo1a+ad5dsd1HU4ZB+B3nMiWbQizaFmD3MrgO
cR/KRJtxKTcXQCBLqIi+t2sDFQ8uozs0xYbGHDrCPgCayZLfAVxGCwP2LANnQKw=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=CH/O=Proton Technologies AG/OU=ProtonMail/CN=127.0.0.1
issuer=/C=CH/O=Proton Technologies AG/OU=ProtonMail/CN=127.0.0.1
---
Acceptable client certificate CA names
/C=CH/O=Proton Technologies AG/OU=ProtonMail/CN=127.0.0.1
Client Certificate Types: RSA sign, ECDSA sign
Requested Signature Algorithms:
(...)
Copy the very first block that begins with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----, paste this into a file and save it with a .pem extension. Let's say you name it protonbridge.pem subsequently saving it in /etc/ssl/certs/, you would need to add this to your ~/mbsyncrc file:
CertificateFile /etc/ssl/certs/protonbridge.pem
This should be it, you should now be able to sync. I did not seem to have to copy the root issuer certificate as explained at the end of the step #1 in the link. If you do mbsync -l channel-name you will see a list of all mailboxes to sync. You may want to add Patterns INBOX Sent if you do not want all and every folder in you Protonmail account to sync, including one called "All Mail"!

I confirm that with Thunderbird Version 91.8.1 (64-bit) and Proton Mail Bridge v2.1.1 You can change SMTP security settings to SSL/TLS on both programs and outgoing mail works.

Related

Understanding openssl. Where is the cert file?

I am using the command ...
openssl s_client -showcerts -connect reds-cluster-01:443
And I get the output:
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
verify return:1
depth=0 CN = *.my-co-example.com
verify return:1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=*.my-co-example.com
i:/C=US/O=DigiCert Inc/CN=RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
-----BEGIN CERTIFICATE-----
MIIGnxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxgkqhkiG9w0BAQsFADBZ
...
I assume that means somewhere on the filesystem of my server there would be a file somewhere that has the string ...
MIIGnxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxgkqhkiG9w0BAQsFADBZ
... in it. How can I find that file without having to execute something like?
sudo grep -sr MIIGnxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxgkqhkiG9w0BAQsFADBZ /
I assume that means somewhere on the filesystem of my server there would be a file somewhere that has the string ...
This assumption is wrong. What you see is part of the server certificate, which need to be checked against a CA certificate located in the local trust store. The server certificate is typically not in the local trust store. See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for more on certificates are checked.
You can see more with "CURL -W CERTS" from Daniel Stenberg (also on Stack Overflow), which works on curl for the past 25+ years.
When a client connects to a TLS server it gets sent one or more certificates during the handshake.
Those certificates are verified by the client, to make sure that the server is indeed the right one: the server the client expects it to be; no impostor and no man in the middle etc.
When such a server certificate is signed by a Certificate Authority (CA), that CA’s certificate is normally not sent by the server but the client is expected to have it already in its CA store.
(So no file to check on the filesystem)
Ever since the day SSL and TLS first showed up in the 1990s user have occasionally wanted to be able to save the certificates provided by the server in a TLS handshake.
The openssl tool has offered this ability since along time and is actually one of my higher ranked stackoverflow answers.
Now (for curl 7.88.0,to be shipped in February 2023), Daniel proposes:
Using the –write-out (-w) option and the new variables %{certs} and %{num_certs}, curl can now do what you want.
Get the certificates from a server in PEM format:
$ curl https://curl.se -w "%{certs}" -o /dev/null > cacert.pem
$ curl --cacert cacert.pem https://curl.se/
That is easier to parse than the openssl s_client -showcerts -connect current alternative.

cURL 60 error when trying to access my website's XML file

When I use "curl -v https://hostname/resource.xml" I get the following error:
About to connect() to hostname.com port 443 (#0)
Trying x.x.x.x... connected
Connected to hostname.com (x.x.x.x) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
Peer's certificate issuer is not recognized: 'CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US'
NSS error -8179
Closing connection #0
Peer certificate cannot be authenticated with known CA certificates
curl: (60) Peer certificate cannot be authenticated with known CA certificates
More details here: http://curl.haxx.se/docs/sslcerts.html
However, when I try: "curl -v https://google.com/"
everything works just fine!
The certificates that validate the websites are located in /etc/ssl/certs
I can assume that this is an issue with SSL certificates and validation because when I run the curl command with -k it works!
I have tried the following to troubleshoot:
Confirmed that date/time is correct on the server
updated the cacert.pem certificate (source: cURL error 60: SSL certificate: unable to get local issuer certificate)
Confirmed that Apache configuration is correct
Tried adding the SSL certificate (website.crt) to /etc/pki/tls
I am running:
CentOS release 6.10 (Final)
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
PHP 7.1.32 (cli)
Would this be caused due to SSLCertificateChain being incomplete?
Any help here is appreciated!
It appears the issuer of your website certificate is an intermediate certificate CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US but it is not sending the full chain, i.e. it is only sending the website certificate without this intermediate certificate. You have 2 options:
Updated the website configuration to bundle the intermediate certificate with the website certificate (preferred method). Follow the instructions here to update the Apache configuration to use the intermediate certificate.
Basically you have to modify the httpd.conf file of your Apache installation, specifically the Virtual Host settings for your website, and point the SSLCertificateChainFile setting to the PEM (crt) file that contains the intermediate cert (CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US)
You can find the intermediate certificate you are missing on the web, for example here, and save this content to a file (e.g. incommon_rsa.crt). Here is what you need to save in the file:
-----BEGIN CERTIFICATE-----
MIIF+TCCA+GgAwIBAgIQRyDQ+oVGGn4XoWQCkYRjdDANBgkqhkiG9w0BAQwFADCB
iDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0pl
cnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNV
BAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQx
MDA2MDAwMDAwWhcNMjQxMDA1MjM1OTU5WjB2MQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCTUkxEjAQBgNVBAcTCUFubiBBcmJvcjESMBAGA1UEChMJSW50ZXJuZXQyMREw
DwYDVQQLEwhJbkNvbW1vbjEfMB0GA1UEAxMWSW5Db21tb24gUlNBIFNlcnZlciBD
QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJwb8bsvf2MYFVFRVA+e
xU5NEFj6MJsXKZDmMwysE1N8VJG06thum4ltuzM+j9INpun5uukNDBqeso7JcC7v
HgV9lestjaKpTbOc5/MZNrun8XzmCB5hJ0R6lvSoNNviQsil2zfVtefkQnI/tBPP
iwckRR6MkYNGuQmm/BijBgLsNI0yZpUn6uGX6Ns1oytW61fo8BBZ321wDGZq0GTl
qKOYMa0dYtX6kuOaQ80tNfvZnjNbRX3EhigsZhLI2w8ZMA0/6fDqSl5AB8f2IHpT
eIFken5FahZv9JNYyWL7KSd9oX8hzudPR9aKVuDjZvjs3YncJowZaDuNi+L7RyML
fzcCAwEAAaOCAW4wggFqMB8GA1UdIwQYMBaAFFN5v1qqK0rPVIDh2JvAnfKyA2bL
MB0GA1UdDgQWBBQeBaN3j2yW4luHS6a0hqxxAAznODAOBgNVHQ8BAf8EBAMCAYYw
EgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUH
AwIwGwYDVR0gBBQwEjAGBgRVHSAAMAgGBmeBDAECAjBQBgNVHR8ESTBHMEWgQ6BB
hj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNh
dGlvbkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNo
dHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5j
cnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI
hvcNAQEMBQADggIBAC0RBjjW29dYaK+qOGcXjeIT16MUJNkGE+vrkS/fT2ctyNMU
11ZlUp5uH5gIjppIG8GLWZqjV5vbhvhZQPwZsHURKsISNrqOcooGTie3jVgU0W+0
+Wj8mN2knCVANt69F2YrA394gbGAdJ5fOrQmL2pIhDY0jqco74fzYefbZ/VS29fR
5jBxu4uj1P+5ZImem4Gbj1e4ZEzVBhmO55GFfBjRidj26h1oFBHZ7heDH1Bjzw72
hipu47Gkyfr2NEx3KoCGMLCj3Btx7ASn5Ji8FoU+hCazwOU1VX55mKPU1I2250Lo
RCASN18JyfsD5PVldJbtyrmz9gn/TKbRXTr80U2q5JhyvjhLf4lOJo/UzL5WCXED
Smyj4jWG3R7Z8TED9xNNCxGBMXnMete+3PvzdhssvbORDwBZByogQ9xL2LUZFI/i
eoQp0UM/L8zfP527vWjEzuDN5xwxMnhi+vCToh7J159o5ah29mP+aJnvujbXEnGa
nrNxHzu+AGOePV8hwrGGG7hOIcPDQwkuYwzN/xT29iLp/cqf9ZhEtkGcQcIImH3b
oJ8ifsCnSbu0GB9L06Yqh7lcyvKDTEADslIaeSEINxhO2Y1fmcYFX/Fqrrp1WnhH
OjplXuXE0OPa0utaKC25Aplgom88L2Z8mEWcyfoB7zKOfD759AN7JKZWCYwk
-----END CERTIFICATE-----
Add the intermediate certificate to the list of system-trusted CA certificates (less-preferred method, intermediate certificates should be sent by clients and not trusted implicitly by adding it to the list of system-trusted CA certs ).
Again, save the intermediate certificate file with the content I provide above and then install it in your list of trusted CA certificates using the CentOS tools for doing this as described here.

UI Path: The Remote Certificate is invalid according to validation procedure

When i am trying to send mail using SMTP it is throwing error as shown below.
Source: Send SMTP Mail Message.
Message: The Remote Certificate is invalid according to the validation procedure.
Exception Type: System.Security.Authentication.AuthenticationException.
I Tried below solutions to resolve.
Disabled Antivirus.
Allowed Less Secure App from my gmail Account.
I have already read below UI Path topics but i didn’t find link to download the trusted certificate.
The remote certificate is invalid according to the validation
Remote Certificate Is Invalid - UiPath
Windows maintains its trusted CAs in a Certification Directory, and you can read more about that here. The server's certificate is either self-signed, or the certifying authority is not part of your Certification Directory (resolving the whole chain of trust).
Since you mentioned Gmail - that's quite unusual since Google Trust Services is trusted by Global Sign, and Global Sign usually is part of the CD. Here's an example of the required certificate for Gmail (SMTP via port 465):
lynxvvv:~ wolfgangradl$ openssl s_client -connect smtp.gmail.com:465 -showcerts
CONNECTED(00000006)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = smtp.gmail.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=smtp.gmail.com
i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
-----BEGIN CERTIFICATE-----
MIIEgjCCA2qgAwIBAgIII4WYR6PlomgwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
(...)
You can always download and install a custom certificate into the store, here's an excellent article from Super User. If we're talking about Gmail, then you could get them from Google directly as well.
Verify the link below. First, we need to disable antivirus.
https://forum.uipath.com/t/the-remote-certificate-is-invalid-according-to-the-validation/37727/3

Another situation where I get X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY

As a followup to this original question:
Unable to get certificate locally
I did solve the original problem as jww answered.
And I have now followed the same steps of importing the certificate chain for our company site, from "comodo". I simply added them to the file which I originally used with the "google.com" root certs.
Now, although this still works fine with "google", when I connect to our company website, I still get the error code 20 on the SSL_get_verify_result() call.
Is this a result of our using a "wildcard" certificate? i.e.: *.domain.com.
The version of OpenSSL I am currently using is 1.0.1g.
I don't see any other differences from my perspective.
Thanks for any advice.
----- Updated ------
First, let me comment that I am not mentioning our domain, and not posting too much material from the OpenSSL command, as I am not familiar enough with what should be kept confidential.
What I did was combine the base64 encoded certificates into one big file, as the previous post instructed. And I obtained them via the browser "export" utility in the same manner for both. That means the certificates that we use, as well as the google certificates from my previous post are all concatenated. Specifically it looks like this now:
Our Company Cert
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
and it is signed by these guys - ComodoRSA
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
and that is signed at the root here - ComodoRoot
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
and this is the GOOGLE G3 who signed the "www.google.com"
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
and the GOOGLE G3 is signed by this one - globalSign
-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----
Then the code segment I use to test looks like this:
strcpy(host,"our.domain.com");
// strcpy(host,"www.google.com");
/* Build our SSL context*/
ctx = initialize_ctx(KEYFILE,NULL);
/* Connect the TCP socket*/
sock = tcp_connect(host,port);
And then later...
result = SSL_get_verify_result(ssl);
switch(result) {
case X509_V_ERR_CERT_HAS_EXPIRED : break;
case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN : break;
case X509_V_OK : break;
case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT : break;
default :puts("Certificate doesn't verify");
}
Simply put, this same code, using this same CRT file, does not give me a "20" error when I use the www.google.com" host, but does give me an error "20" when I use our server. The extent of the test involves changing that commented out name of the host.
Connections to the HTTPS server with commercial clients (Chrome, IE, FF...) have no errors.
As for the comment that recommended the command, I get the following (hopefully I pasted the necessary information):
For Google:
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = www.google.com
verify return:1
read:errno=0
---- other stuff ----
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.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
---
And for our domain, I am getting the following (company specifics hidden):
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify error:num=20:unable to get local issuer certificate
verify return:0
read:errno=10054
---- other stuff ---
Certificate chain
0 s:/C=US/postalCode=00000/ST=IL/L=city/street=main/O=company./OU=PremiumSSL Wildcard/CN=*.domain.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
----
Now, the chain is that our certificate is signed by "ComodoRSA", and that it is signed by "ComodoRoot".
However, as I originally indicated, our certificate is a "wildcard" certificate, where the google certificate isn't.
So that was my question: Is there a problem using wild card certificates with the version of openSSL 1.0.1g?
--- EDIT2 ----
I am adding more content to the post, so I can include an image from the browser.
Our certificate is on a live web site, and is not self signed.
I am checking the common name in a portion of the code not shown. In this post I am only hoping for advice on this error.
I found a site that uses the same chain we use: DrudgeReport.com
I simply extracted the certificates with the browser, and saved them into a file. This was identical to the steps I used form the google.com site. (View certificate and copy to file)
The result from Drudge is error 19 which is "self signed", not error 20 which was my error. The root level (comodo secure) is the same when I copy to file from either site (as I would expect).
As I learn this from your comments and the link, I see the next intermediate question is: how do I know what certificates are being sent by the server, and which were in the store? Then I would know which to import. What, if any, is the indicator from the openssl command output you provided?
The educational material on openssl and this is rather difficult to find. Just a lot of doc, which to a novice such as myself, is rather circular in it's definitions.
Thanks for your feedback so far.
So that was my question: Is there a problem using wild card certificates with the version of openSSL 1.0.1g?
It is not a problem of wildcard certificates. In fact, your code does not even check the subject of the certificate at all (i.e. your code is insecure), it mostly checks the certificate chain, expiration and purpose of the certificate. And the error message from openssl s_client clearly points out the problem:
verify error:num=20:unable to get local issuer certificate
Thus, the problem is not the certificate subject but that it cannot find a local trust anchor. Looking at the certificate chain provided by your server gives the following certificate chain:
[1] CN=*.domain.com, issued by [2]
[2] CN=COMODO RSA Organization Validation Secure Server CA, issued by [3]
[3] CN=COMODO RSA Certification Authority, issued by [ROOT]
The expected [ROOT] is "CN=AddTrust External CA Root" - only this CA is not in your list of trusted root CA.
While you give not the detailed names of the certificates you have in your local trust store my guess is that the CA you call "ComodoRoot" is similar to what I have as "[3] CN=COMODO RSA Certification Authority" in the list. Only, in your trust store it is likely the self-signed version of the certificate while in the certificate chain provided by the server it is a certificate issued by "[ROOT] CN=AddTrust External CA Root". Both certificates have the same public and private key which means that the signatures in certificate chain can be successfully validated with both.
But, the old (and long unsupported version) of OpenSSL you are using can not properly deal with this kind of situation. It will follow the certificate chain send by the server and then expect the last certificate in the chain signed by on of the certificates in your trust store. If this fails it will not check if a shorter chain might be validated successfully instead.
This means it will succeed if you either have "CN=AddTrust External CA Root" in your trust store or if the server sends a short chain which ends with "[2] CN=COMODO RSA Organization Validation Secure Server CA" since then it will find the issuer for this (your "ComodoRoot", i.e. "CN=COMODO RSA Certification Authority") in your trust store.
For a more detailed explanation of this problem see this answer at stackoverflow.com or this article. Note that there is no way to fix this in code with OpenSSL 1.0.1 - you need to either add the missing certificate to your trust store or make changes to the certificate chain send by the server.

openssl s_client Error: verify error:num=2:unable to get issuer certificate

I need to connect to some https://website.com. So, the site is available via VPN. I'm connected to the VPN and I can open the site in browser.
I've downloaded certificates from browser:
Then I cat both file into one certificate.pem
But when I'm trying to execute command
openssl s_client -connect website.com:443 -CAfile /path/to/certificate.pem
When I execute it in a terminal I have an error.
CONNECTED(00000003)
depth=1 /C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
verify error:num=2:unable to get issuer certificate
issuer= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
verify return:0
---
Certificate chain
0 s:/C=AU/ST=Wales/L=Place/O=Company
Ltd/OU=D&D/CN=website.com
i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/C=AU/ST=Wales/L=Place/O=Company
Ltd/OU=D&D/CN=website.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 2034 bytes and written 328 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES128-SHA
Session-ID: 1533BA958D51B9FEAE4C3534F4A417A5896ED17DCAAE83E89E6C2A7F615A583A
Session-ID-ctx:
Master-Key: 5CF D4ACA242B602AAFSDF1234X23E99BD4C62862888947FACFF0E7503BA34C2DD0EC193FA525204A539
Key-Arg : None
Start Time: 1509781851
Timeout : 300 (sec)
Verify return code: 0 (ok)
openssl historically and by default validates a certificate chain only if it ends at a root. Having the server aka end-entity or leaf cert in the truststore is useless, and the intermediate(s) should not be needed because RFCs require the server to send it(them), but your server is apparently defective or misconfigured because it does not. Thus for your server having the intermediate and root, but not the server cert, in the file used for -CAfile will work, assuming they are in PEM format.
Alternatively, recent (and supported) releases 1.0.2 and 1.1.0 add an option -partial_chain. If specified, this validates if the truststore has any anchor, not just a root. For your server, having either the server cert or the intermediate in the file used for -CAfile is sufficient, again in PEM format.
These cases are described on the man page for verify(1) which is referenced from the man page for s_client(1). Some systems may make the section 1ssl or similar, and if your system is not properly installed or is Windows, they are on the web here.
Remember that openssl historically and by default does not check the server name in the cert. 1.1.0 has new options -verify_name and -verify_hostname that do so. These are described on the man page for verify and referenced on that for s_client.
Also remember that many servers, though apparently not yours, now use Server Name Indication (SNI) extension to support multiple 'virtual' hosts with different certificates, and will either give a wrong cert or reject or fail the connection if SNI is missing. openssl s_client does not send SNI by default, but the option -servername does so; this is described on the man page. Update: OpenSSL 1.1.1 in 2018 s_client now does send SNI by default.
In general looking at the man pages for a program tells you useful information about how the program works and how to use it, and is recommended.
Especially since this is not a programming or development question, and really off-topic for StackOverflow; I would try to propose migration to SuperUser or ServerFault, but they already have numerous dupes.
This error means that openssl is looking for the issuer certificate with the subject "/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA" but it is not provided in the file /path/to/certificate.pem. Suggest to run "openssl x509 -in /path/to/certificate.pem -text" to see the subject of the certificate in this file - should be different from the requested one.