PayPal SSL Certificate Change: Testing Verisign G5 Certificate - ssl

I'am trying to confirm, that our server will be ready for the SSL Certificate Change.
According to Microsite migration on www.sandbox.paypal.com is complete.
Running:
openssl s_client -CApath /etc/ssl/certs/ -connect www.sandbox.paypal.com:443
returned 0 (ok)
Does this test definitively confirm that our server is ready?

The openssl connection return code(0) will be affirmative for this cert check, but there’s a slightly change you may want to make for the call.
Run with the following line and try the conn one more time, (I’ve added the –showcerts parameter so that the cert chain will be printed out and you may easily identify Verisign G5 root cert in there)
openssl s_client -connect api-3t.sandbox.paypal.com:443 -showcerts -CApath /etc/ssl/certs/

Related

getting ` x509: certificate signed by unknown authority` error while verifying certificates for rest application

I am generating a self signed certificate using openssl in Ubuntu. I want to use it for localhost rest server. But while verification, I am getting error : x509: certificate signed by unknown authority, can anyone please tell me how I can resolve this error?
Thanks!
Place your root certificate and intermediate (if you have one) in /usr/share/local/ca-certificates with the .crt extension.
Run:
sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
In this case, curl is your friend:
curl -Iv https://localhost/path/to/api
Also you can run openssl s_client
openssl s_client localhost:443
Additionally, you can interrogate your certificate by providing your certificate:
openssl s_client -connect localhost:443 -CAfile /path/to/your/cert.pem
If you certificate does not match, you know. Possibly you are using the wrong certificate for your REST API or the certificate is not being installed, which you can verify by looking in /etc/ssl/certs directory on your system (if you are running Linux)
Place your .crt certificate to /usr/share/ca-certificates
Edit /etc/ca-certificates.conf and add your certificate name there.
(Look at update-ca-certificates man page for more information.)
Then run sudo update-ca-certificates
Works for me in Ubuntu 22

openssl s_server mutual TLS

I can use the openssl s_server command to accept TLS sessions from clients, and to require mutual TLS - i.e. request client certificate - using a command such as: -
openssl s_server -accept 4433 -cert myCert.crt -key -myKey.pem -Verify 2 -CAfile myCA.crt
When I connect from a client, I can see from tracing that s_client sends a certificate request, correctly stipulating the certificate contained within myCA.crt. However it seems that s_server will accept any client certificate, regardless of whether it was signed by myCA.crt or not - i.e. it doesn't care which client cert is sent.
Does anyone know if this is expected behaviour, or am I doing something wrong?
openssl s_server and s_client by default verify the peers certificate and show the verification status but don't stop on errors. If this is necessary use the -verify_return_error option.

TLS Mutual Auth: null cert chain (C client -> Java server) unless cafile points to same file as cert

I have an issue with the server rejecting the client certificate in the handshake if I issue openssl call with just the cert (with chain) and private key.
This issue goes away if I also set the cafile param and point it to the same file as the cert.
It seems as if openssl cannot construct the chain without the cafile input even if the information is already in the cert input. I wonder if you guys had experience with this. I just find it a bit odd.
To summarize, this works:
sudo openssl s_client -connect <ip>:<port> -cert cert_with_chain.pem -key privkey.pem -CAfile cert_with_chain.pem
This doesn't work (Server reject with "null cert chain"):
sudo openssl s_client -connect <ip>:<port> -cert cert_with_chain.pem -key privkey.pem
Open SSL version:
OpenSSL 1.0.2k-fips 26 Jan 2017
The problem is not that "openssl cannot construct the chain without the cafile" but that it wasn't the intention in the first place to do so. The intended behavior is well documented in man s_client:
-cert certname The certificate to use, if one is requested by the server.
-CAfile file A file containing trusted certificates to use during server authentication and to use when attempting to build the client
certificate chain.

Error Connecting to EPP Server Using openssl s_client

I'm currently trying to connect to an EPP server using openssl s_client to verify my connection. The below command outputs the following.
openssl s_client -connect example.com:700
Response:
CONNECTED(00000003)
depth=1 /C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
41282:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL0 98-64.30.2/src/ssl/s3_pkt.c:1145:SSL alert number 40
41282:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.30.2/src/ssl/s23_lib.c:185:
I then proceeded to download the DigiCert SHA2 Secure Server CA from https://www.digicert.com/CACerts/DigiCertSHA2SecureServerCA.crt
I then re-attempted using a self-signed cert created with openssl, along with the new DigiCert certificate.
openssl s_client -connect example.com:700 -CAfile DigiCertSHA2SecureServerCA.crt -key key.pem -cert cert.pem -debug
And I get the same error. What could I be doing wrong here?
From the information you provide the client gets the certificate from the server and continues with the handshake but then gets a handshake_failure (alert 40) back from the server. Getting this error at this stage of handshake is likely caused by the server expecting to get a client certificate which the client did not provide. But, to be really sure one would need to have more information, ideally a full packet capture of the connection.
If you are using a self-signed certificate you should use the same file for both -CAfile and -cert. If you are using DigiCert CA in -CAfile then in -cert it should be a certificate signed by DigiCert.
Also the server needs to accept your certificate, which means it needs to have its CA (and possible intermediate CAs) beforehand.

Check enddate for intermediate certificate in chain

I recently had a problem where a server certificate was not set to expire, but the intermediate cert in its chain had expired, thus preventing my WebLogic server from starting. I am familiar with using openssl s_client -connect server:443 -showcerts | openssl x509 -enddate to get the server cert expiration date, but is it possible to do the same for the other certs in the chain? Thanks.
openssl s_client -connect server:443 -showcerts returns all certificates in chain except for root (which is correct). Just parse these certificates out of the output and run openssl x509 -enddate on each of them.