My production app uses ActiveMerchant and is unable to process credit cards over https with a single gateway, Moneris. All other gateways Authorize.net, Paypal, Beanstream, etc) experience no errors. The error I receive is:
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed):
The people at Moneris have told me that they have updated their SSL certificate
to 2048bit SSL encryption (from the current 1024 SSL encryption) and that the upgraded certificate will be issued by VeriSign. Our wildcard SSL uses 2432--more than the Moneris 2047 requirement.
So, they suggested that in addition to the files I normally upload for my SSL bundle, I have to add their Verisign certs. My Heroku command looks like this:
$ heroku certs:upgrade --app myapp AddTrustExternalCARoot.crt ComodoUTNSGCCA.crt EssentialSSLCA_2.crt STAR_myapp_com.crt UTNAddTrustSGCCA.crt Verisign_chain_Gr.cer Verisign_G5.cer server.key
I have tried virtually everything including the fix_ssl.rb suggestion here (OpenSSL::SSL::SSLError on Heroku) where I call the ca-certificates.crt from my /usr/lib/ssl/certs directory from Heroku.
require 'open-uri'
require 'net/https'
module Net
class HTTP
alias_method :original_use_ssl=, :use_ssl=
def use_ssl=(flag)
self.ca_path = Rails.root.join('/usr/lib/ssl/certs/ca-certificates.crt').to_s
self.verify_mode = OpenSSL::SSL::VERIFY_PEER
self.original_use_ssl = flag
end
end
end
I've tried everything: placing the Heroku bundle in my /lib directory, adding the 'certified' gem, etc, etc. and spent hours on the phone with Moneris to no avail. Does anyone know what more I can do to allow this one gateway to process credit cards?
My guess is that the trusted list of CA certificates that openssl is using to verify Moneris' server certificate is out-dated. So try getting the cacert.pem extracted from Mozilla's ca-bundle (http://curl.haxx.se/docs/caextract.html does this for you). This is more necessary these days as far as openssl is concerned as openssl is no longer bundled with CA certs which is why I'm suspecting whatever ca-certs you're using might be out of date.
First I tried to reproduce your problem with the command:
openssl s_client -connect www3.moneris.com:443
and got ...
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : RC4-MD5
Session-ID: 73178D4019035AE86399D0E6D2FFB904A1412D0F5D3F83370E52F50E9E26B73C
Session-ID-ctx:
Master-Key: 0BB841912F11185B7CBAFA524571765DD7372990819EBC44E311DE4EF0C70E480501D6F87C8AA439C4F827B0908123F7
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1380816775
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
Then I used the cacert.pem extracted from Mozilla thanks to http://curl.haxx.se/docs/caextract.html
and re-issued the openssl command like so:
openssl s_client -connect www3.moneris.com:443 -CAfile cacert.pem
and got ...
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : RC4-MD5
Session-ID: 73178D401902F7EB6399D0E6D2FFB804CE0F7219344405EA0E52F50E9E26B4DB
Session-ID-ctx:
Master-Key: C0B32810FB7E0158A156E7D05DBB35F3CE8935284F165C3FB636700EEEC8BCE991BCE8850D39020E298F337B6E58132A
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1380816992
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
So in your code snippet, above, try replacing:
self.ca_path = Rails.root.join('/usr/lib/ssl/certs/ca-certificates.crt').to_s
with:
self.ca_file = <full path name>/cacert.pem
where cacert.pem is extracted from the Mozilla ca-bundle
Related
When I do openssl s_client -CApath ~/cacert.pem -crlf -connect getcomposer.org:443 -servername getcomposer.org I get the following output:
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/CN=getcomposer.org
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFTzCCBDegAwIBAgISA4wAKXUPtnZXoYnne5MGiWlHMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA5MzAxMDI5MDlaFw0yMTEyMjkxMDI5MDhaMBoxGDAWBgNVBAMT
D2dldGNvbXBvc2VyLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMSpt0JoJU7PJQYHYWV5FRTheIQSFi3SM/qyt2RDwKG4g7QssLjmsAXKQ5ZgGNc2
0JOaJ6NS3LgckijVOBOgBpywXTBJ0XOF6JJpjmuivdHXw0tssD+7BD+9Z30M9vCV
i5OU2dw6VmPi7M/J9haO+/ONuMpojmPTI2IKQl7w13y+AN+EqOVn5tWKgMpKxY9y
dydsbqgGffa7aSuN4Rc6UXZ4ix4mfSdjrAxFsKeOAmVh8NfQ49PoEpNAIce7ZQkF
hzq1AZmBtpe76LYrNEO55bPbg5Z9NPBReBpVG4tpLVWPUrarxdhCLD+F5b3s7Ko/
SzAWf/mX/K89Zdd3G8q52gECAwEAAaOCAnUwggJxMA4GA1UdDwEB/wQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNV
HQ4EFgQU6Z7XW6cbc9xNki5IDKUmJEgZrJ8wHwYDVR0jBBgwFoAUFC6zF7dYVsuu
UAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8v
cjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9y
Zy8wQwYDVR0RBDwwOoISY2EuZ2V0Y29tcG9zZXIub3Jngg9nZXRjb21wb3Nlci5v
cmeCE3d3dy5nZXRjb21wb3Nlci5vcmcwTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYL
KwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlw
dC5vcmcwggEGBgorBgEEAdZ5AgQCBIH3BIH0APIAdwBc3EOS/uarRUSxXprUVuYQ
N/vV+kfcoXOUsl7m9scOygAAAXw2dyOHAAAEAwBIMEYCIQCOGcPZTl5eD4E03Ted
RabOF+lXzyXOPBT3xDtrIYmgxgIhAJAJJzdWzyzX8f6TdbIzGr7xQFhQAIHn/3+1
8ffWn/FjAHcAfT7y+I//iFVoJMLAyp5SiXkrxQ54CX8uapdomX4i8NcAAAF8Nncj
ywAABAMASDBGAiEA97oAvcGhneZl1n+meqzcb6OK5SJoUxYmdlz5LO15BpICIQCL
jrrvGdWMIV/ujHDMAvQ4QUn25GBjf6kps6d6SO6xADANBgkqhkiG9w0BAQsFAAOC
AQEAciXzEuFF5zwYpwv65AkhD1yYGvsqjRNCAe+AqvBVPEfqES/kCBCKeM5UDpAV
+TuJq7OQAGyUHbSAf0JK9DGTN0chTJVShaJEAXgIvnykolab/eNwpxrEOG5wTpRz
p5bJQfR+kVVIyjg0BknDQZMopH1MtWny8LT3jqhBV9eAFaaBh/X46liDACe2VmRv
/MHYGZtMtVnYIcm4iqPMZShMrWkPB7mO6PrUo0QzAUhMpb/KCRb/2XIf+H2I9zzJ
Y5MhKksA3NqDLFW3dD/KrnLKkqtKiOsUGgG1yDR9+S64lNS+IswcsodirXyrtbac
pZAfDeIuhhZ8uGqZhfcdC2OONw==
-----END CERTIFICATE-----
subject=/CN=getcomposer.org
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
---
SSL handshake has read 3183 bytes and written 455 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 222874F43D8C5CD5C5EBCE9519D767FC0847D4BCE75261020AEDA2337E84CE87
Session-ID-ctx:
Master-Key: 4C7B19187830AF58A6D03B37163A5C2CEF3222F6BC048D569B122DF372DFCA4CB7FAA0103AAE0C87B5C008E0692C48AD
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1634183395
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
closed
I don't understand this error. I just got cacert.pem by doing wget --no-check-certificate -O ~/cacert.pem https://curl.se/ca/cacert.pem and doing vim ~cacert.pem verifies that the newly created file is non-empty.
Since the community seems to have accepted this as ontopic:
As I commented, to use in openssl commandline a 'bundle' file in the format supplied by https://curl.se/ca/cacert.pem you must use -CAfile not -CApath.
-CApath works instead with a directory containing a separate file for each cert named by its subject hash, as described in man 1 verify on older versions or man 1 openssl-verification-options on 3.0 also here on the web and which you can use c_rehash to help create if that is really wanted for some reason.
This is a stab in the dark, as I don't understand that openssl output much, but judging by the timing and the keywords 'openssl' and 'Lets Encrypt' this has a reasonably high chance of success.
On September 30, 2021 Let's Encrypt's old Root Certificate has expired. This had a major implication that now they have started to use their own root cert which should be trusted by most devices. 'Most' part was troublesome as there are some devices alive which did not receive updates in years. So the people at Let's Encrypt found a way to still remain supported/trusted on those devices, just under one condition - its openssl version must be 1.1.0+ (which is already 4+ years old). Another important detail is that this openssl version requirement also applies to systems that would have otherwise trusted LE's new cert.
So I've seen numerous people over October scrambling to get LE issued certificates to be trusted again by their systems and the answer was always as simple as: Get your openssl / libopenssl updated to v1.1.0+
I have created a private mail server using iRedMail & Nginx. I have installed SSL certificates and keys into Nginx and iRedMail itself at the below locations. The server runs great and everything works via web mail. The browser agrees that the SSL certificate is valid and HTTPS works.
The issue is when I add the mail account to my email client, I get an invalid certificate error, and the same issue when using CalDav. It still works, but this makes me think that I'm missing some certificate install somewhere. Any suggestions? Thank you!
/etc/ssl/certs/iRedMail.crt
/etc/ssl/private/iRedMail.key
Here is the output of openssl s_client -showcerts -connect mail.bragsdale.dev:993
CONNECTED(00000003)
depth=0 CN = bragsdale.dev
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = bragsdale.dev
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=bragsdale.dev
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
...CERTIFICATE HERE...
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=bragsdale.dev
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2064 bytes and written 431 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
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 3DD2E8B607CF5B4ACECDB995078FDAE80C210097372B80CD1409E90A0A523E0A
Session-ID-ctx:
Master-Key: F1953ABEAC1024279DA6D0E17D26E3305E7C2A9589976FDFD2DBF22E4B6280415BC271E5228045B7D0C5E8A0B3921B11
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
....DATA HERE...
Start Time: 1551664367
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready
Fixed it. The problem was I wasn't using my intermediary certificate. See this answer for details.
A note, when I cat'ed the certificates together it was malformed, with the END CERTIFICATE/BEGIN CERTIFICATE being on one line. Easily fixed with a text editor.
I am trying to establish ssl connection with rabbitmq broker.
I follow this page to help me and I find my bug, but I don't know who to resolve it. I am stuck at the test connection with the broker :
openssl s_client -connect localhost:5671 -cert client/cert.pem -key client/key.pem -CAfile testca/cacert.pem
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1470206187
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
And I have no log but I need accepting AMQP connection.
#Rabbimq.conf
[
{rabbit, [
{ssl_listeners, [5671]},
{ssl_options, [{cacertfile,".../testca/cacert.pem"},
{certfile,".../server/cert.pem"},
{keyfile,".../server/key.pem"},
{ciphers, [{rsa,aes_256_cbc,sha256}]},
{verify,verify_peer},
{fail_if_no_peer_cert,false}]}
]}
].
The certificates that I use are validated, verified and created with the doc.
I think is this issue that does not allow me to perform a ssl connection.
Thanks
Edit: I created the certificates at /var/lib/rabbitmq with the user rabbitmq and like this permissions goes right and the server can access to the certs.
Everything worked for me after I replaced in rabbitmq.config
{certfile,".../server/cert.pem"},
to full file path.
{certfile,"/data/server/cert.pem"}
The rabbitmq says nothing when it can't find or can't read certificate file.
Check permissions for certificate files!
I'm not sure what argument do I have to pass to switch -id_prefix for openssl s_server.
What I am trying to do is to run openssl s_server on one side, and openssl s_client on the other, and verify that Session-ID and Master-Key matches on both sides.
The problem is, that I only get to see the Session-ID and Master-Key on the client side. I'm not sure how to obtain them on the server side as well, so I can compare them.
id_prefix seems to be one option, but I don't see the prefix in the Session-ID on the client side.
Any ideas?
I can see how you can check the Master-Key using openssl s_server and openssl s_client, but not the Session-ID; I'm not sure why.
Here's what I did. First, I started a server running locally:
$ openssl s_server -accept 4433 -cert ./server.pem -tls1_2
Then, in a different terminal/window, I connected to that server:
$ openssl s_client -connect 127.0.0.1:4433 -debug
In the server terminal, I saw the SSL session started:
Using default temp DH parameters
ACCEPT
-----BEGIN SSL SESSION PARAMETERS-----
MFUCAQECAgMDBALAMAQABDDAOWXb47pESLXfWW1DYfaccOPGQcfgeaHW4sFP/avj
ejwVgvWNXGXy1vn6U3uLOeWhBgIEVqrm26IEAgIcIKQGBAQBAAAA
-----END SSL SESSION PARAMETERS-----
...
CIPHER is ECDHE-RSA-AES256-GCM-SHA384
Secure Renegotiation IS supported
The key thing thing to notice here is that base64-encoded data for the SSL session parameters. I copy and pasted that data into a separate file, e.g. sess.pem.
Then, I used openssl sess_id to decode that sess.pem file:
$ openssl sess_id -noout -text < ./sess.pem
SSL-Session:
Protocol : TLSv1.2
Cipher : C030
Session-ID:
Session-ID-ctx: 01000000
Master-Key: 9C921511052D3F212FF718704518FC526474D69FC26BC1165DBD203C6E221BB3A84686BC5D15A7BD9FA7BB72201A7276
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1454040610
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Compare that Master-Key value with the one that the openssl s_client terminal shows (note that it's important to use the -debug command-line option for openssl s_client to see this):
...
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 417D443BFD5702BEA974C5758FD65A0FC217B0FD9750C4CECF0915895C4E616D
Session-ID-ctx:
Master-Key: 9C921511052D3F212FF718704518FC526474D69FC26BC1165DBD203C6E221BB3A84686BC5D15A7BD9FA7BB72201A7276
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
....
So I'm not sure why the server output doesn't show the session ID generated, but you can at least use the above to compare the Master-Key values. I experimented with using both the -context and -id_prefix command-line options for openssl s_server, e.g.:
$ openssl s_server -accept 4433 -context FOO -id_prefix BAR ...
but it did not substantially change the data, nor did it cause the Session-ID to be displayed by openssl s_server.
Hope this helps!
I have an Android app that has some trouble with a site's certificate when connecting via https. As I'm experiencing trouble even when using a custom keystore with the certificates ("No peer certificate") I'm trying to get more information about the connection, handshake and certificates actually given by the server.
The version of openssl is follows:
$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
When I just try to get info about the certificates I get this response:
$ openssl s_client -showcerts -connect [hostname]:443 </dev/null
CONNECTED(00000003)
3069977808:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:749:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
This is how Chrome describes the connection (sorry for the Norwegian text, but you get an idea of the connection and encryption type:
Based on the info from Chrome I've tried different commands to get the certificates, but they all seem to fail. My top candidate was this one:
$ openssl s_client -showcerts -connect [hostname]:443 -tls1_2 -cipher RC4-MD5
CONNECTED(00000003)
3069396176:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1258:SSL alert number 40
3069396176:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1414399499
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
Anyone got any hints based on the info given?
This might be an SNI issue, where the server has no default certificate defined for non-SNI clients. Android included a version of Apaches httpclient which is known to not support SNI and your openssl s_client command also does not use SNI.
Please try openssl s_client -servername hostname -connect ... to use SNI and see if this helps.