Having problems installing PayPalCommerce in OpenCart,
After installing and trying to connect to PayPal I get this error!
"(60) SSL peer certificate or SSH remote key was not OK"
As anybody else come across problem as the server certs are just fine?
As Stated Server Certificats are fine, was thinking of changing the Curl SSL Veerify to False but that would defeat the whole purpose. And as the latest Security 1.2 (whatever abrevation).
Update your certificate authority bundle so that your HTTPS connection to the PayPal API endpoint can verify the connection is trusted.
One can be downloaded here, among other places.
If your attempted connection is using a specific certificate file rather than a CA bundle, delete the old certificate and either obtain the endpoint's current one to use instead or use CA verification of it
Related
I'm trying to understand how to implement client certificate authentication with Kestrel/ASP.Net Core 6.0 on Windows.
So far I was able to successfully authenticate Firefox and Edge with a client certificate to my server prototype.
Now I want to test failures of client certificate authentication due to invalid certificates and decided to begin with a certificate which has expired.
The first issue I faced was that the browsers I am using are not willing to offer the expired certificate for authentication after I imported them into the MS certificate store, so I was hoping that a more versatile client like curl would allow me to do that.
So I set up WSL and figured out how to successfully authenticate curl with a (valid) client certificate to the server.
Then I switched to an expired certificate and happily noticed that I could not connect.
But after looking more closely at the scenario I'm getting the impression that this is because already curl seems to check the certificate and does note seem to even try to use it -- the reason for me to believe this is that my breakpoint in the certificate validation handler of the server are not hit, while they are hit when I'm testing with a valid certificate. In addition, when I disabled the ValidateValidityPeriod in the server CertificateAuthenticationDefaults options this did not have any effect.
(On the other hand, the pertinent message in the curl output
* TLSv1.2 (IN), TLS alert, certificate expired (557):
* OpenSSL SSL_read: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired, errno 0
starts with TLSv1.2 (IN) - this seems to indicate that the certificate validation failure is on server side, doesn't it? I have to admit that I'm confused.)
Has anyone experience with testing the server side of client certificate validation and could hint me
either to convince curl to use the expired (or otherwise invalid) client certificate or
explain to me why the validation handler in Kestrel are not hit in the debugger or
suggest a different tool for that purpose?
(I alread tried the --insecure switch of curl, but that did not seem to help. I was also considering to write my own client, but I don't like testing self-written software with self-written tools).
As part of updating the SSL/TLS certificate of the web server deployed in the Kubernetes(which the current one will expire soon), I updated the Kubernetes secret (kubernetes.io/tls) with the new crt and key.
After that, the application works fine in the browser.
But, the API calls to the server, (From some python applications running in some pods) are hitting some SSLError.
The same will work if I restore the old certificate for the server.
The error is:
requests.exceptions.SSLError: HTTPSConnectionPool(host='hostname',
port=443): Max retries exceeded with url: URL(Caused by
SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: unable to get local issuer certificate
(_ssl.c:1131)')))
I tried to resolve this by creating the crt and key in different ways from the pfx file.
But the issue remains.
I did some search on - if anything to update in the Kubernetes cluster as part of the certificate change and I couldn't find a solution.
Any help will be greatly appreciated.
The issue was, the certificate I installed was without the intermediate certificate. The browsers may "fill in the gap" by searching for the missing certificate. Re-install the certificate with the complete chain resolved the issue
Problem Background:
As part of the Computer Networking course assignment, I have been given task of implementing a Proxy Server ( using python socket and ssl module ) that handles https communications between the browser and the origin server (The real server that my browser wants to talk to).
What I have done so far:
I have implemented the above requirement using ssl sockets and also generated self-signed 'cert.pem' 'key.pem' files.
What I need to do:
Now I just need to tell my browser (chrome 89 on kubuntu 20.04) to accept this self-signed certificate and then test the working of my proxy server.
Reading from this stackoverflow question, I can see that I have to:
(1) become my own CA (2) then sign my SSL certificate as a CA. (3) Then import the CA certificate (not the SSL certificate, which goes onto my server) into Chrome.
My confusion/question:
So if I do this, when eventually I am done with this assignment, how do I reverse all these steps to get my browser in the previous state before I had made all these changes. Also, how to reverse the "become your own CA" and also delete the SSL certificates signed by my CA.
Basically, I want my system to return to the previous state it was before I would have made all these changes.
UPDATE:
I have done the previously outlined steps but now I get an error.
Here is a snippet of my code:
serv_socket = socket(AF_INET, SOCK_STREAM)
serv_socket.bind(('', serv_port))
serv_socket.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
context = context.load_cert_chain('cert.pem', 'key.pem')
context.set_ciphers('EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH')
serv_socket.listen(10)
socket_to_browser, addr = serv_socket.accept()
conn_socket_to_browser = context.wrap_socket(socket_to_browser, server_side=True)
At the last line conn_socket_to_browser = context.wrap_socket(socket_to_browser, server_side=True) an exception is thrown: [SSL: HTTPS_PROXY_REQUEST] https proxy request (_ssl.c:1123)
What am I doing wrong ?
As glamorous as "becoming your own CA" sounds, with openssl it basically comes down to creating a self-signed certificate, and then creating a directory where some CA-specific configuration will be stored (I don't fully remember the specifics, but I think it was just some files related to CNs and serial numbers) so basically reversing the "become your own CA" step is something as mundane as deleting this directory along with the private key and self-signed certificate you were using for the CA. That's it, the CA is no more.
And for chrome returning to the previous state, you would just go the the CA list where you added the CA certificate, select it and delete it. Chrome will stop accepting certificates signed by your CA.
Regarding your new problem... In my opinion, you have developed some kind of reverse proxy (meaning that you expect normal HTTPS requests that you then redirect to the real server) but you have configured Chrome to use it as a forward proxy. In this case, Chrome does not send it a normal HTTPS request, it sends a special non-encrypted CONNECT command and only after receiving the non-encrypted response, it negotiates the TLS connection. That's why openssl says "https proxy request" because it has detected a "https proxy request" (a CONNECT command) instead of the normal TLS negotiation.
You can take a look at How can a Python proxy server (using SSL socket) pretend to be an HTTPS server and specify my own keys to get decrypted data?
It's python, but I think that you'll get the idea
Sim800 supports SSL protocol. AT command "AT+CIPSSL" sets TCP to use SSL function.
In the "sim800_series_ssl_application_note_v1.01.pdf" is noted that: "Module will automatic begin SSL certificate after TCP connected."
My Problem: What is the exact meaning of the begin SSL certificate? what does sim800 do exactly? Does sim800 get SSL certificate from website? where does sim800 save SSL certificate?
As far as I know, SIM800 has some certificates in it and when you use a TCP+SSL or HTTP+SSL connection it will automatically use those certificates.
If those certificates are not ok for you, you will need to use an SD card, save there the certificates you want and use the command AT+SSLSETCERT to set the certificate you saved on your SD card. Here you can find how to use the File System.
Usually the certificates that come with the module are enough and you won't need this. But for example they didn't work for me when I tried to communicate with Azure via MQTT. I had to encrypt the data myself using wolfSSL library and send it using TCP without SSL.
Note: Not all SIM800 modules have SD card support.
There are a very few information about sim800 and ssl certificate on the web, and like you i got a lot of questions about it.
About your questions on how does sim800 get certificate and where does it save it, it seems, according to sim800_series_ssl_application_note_v1.01.pdf, that you can create (defining your own path), write and import a ssl certificate on your own with the AT+FSCREATE, AT+FSWRITE and AT+SSLSETCERT commands. An example is provided at the paragraph 3.10.
I'm sorry, i can't answer your other questions.
Anyway, if you get further informations about sim800 and ssl, i would be grateful if you share it with me.
When you use AT+CIPSSL you tell the SIM-module to use the SSL connection with TCP. When you use +CIPSTART command->
SIM module requests the TCP connection with the server through SSL.
Server sends the Server SSL certificate.
The authenticity of that certificate is checked with internal certificate authority certificate (The one that resides inside SIM-module) which is cryptographically connected with server certificate.
If the authenticity of certificate can not be confirmed SIM-module will close the connection unless you use the command AT+SSLOPT=0,0 (which forces the SIM-module to ignore invalid certificate authentication) prior to AT+CIPSSL command.
//Key exchange
SIM-module then encrypts it's master key (already inside SIM-module cannot be changed or read) with the public key (Which is part of the already sent server certificate) and sends it back to server.
Server then encrypts it's master key with SIM-module's master-key and sends it back to SIM-module. Key exchange is now complete as both (server and SIM-module) recieved master keys.
SIM-module currently doesn't support Client authentication which means that server cannot authenticate the client. That means there must be some other option of authentication (For example in MQTT that can be username and password that only client knows)
If you want your module to be able to authenticate server you will need to create the self-signed certificate for server and certificate authority certificate (for SIM-module) which is cryptographically connected to self-signed certificate and upload them to server and SIM-module (through AT+SSLSETCERT command from SD card).
If you only want to encrypt the data traffic you can ignore invalid certificate (AT+SSLOPT=0,0) as you will recieve publickey nevertheless. But if you want to be sure about server authenticity you will need to upload right certificate to module.
My app connects to Worklight server through HTTPS through self-signed certificate. The app can be launched successfully.
However, when there is direct update which started downloading file from Worklight server, it is failed and I can see that there are error message regarding certification path not found.
May I know if the SSLHandshakeException and direct update error are correlated?
Thanks!
(Environment: Worklight 5.0.6.1, WAS ND 8.5, Testing Device: HTC One)
10-31 21:24:50.897: W/System.err(28746): Catch exception while startHandshake: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
10-31 21:24:50.897: W/System.err(28746): return an invalid session with invalid cipher suite of SSL_NULL_WITH_NULL_NULL
10-31 21:24:50.927: E/WLDroidGap(28746): Failed downloading application update file.
Yes, the use of direct update and the SSL handshake errors are related. Android doesn't allow you to work with self-signed certificates (unless you somehow bypass SSL). Because you can't install a self-signed cert into Android's truststore, the Android client can't establish trust for the server's self signed certificate.
You probably have the following flag specified in your Android manifest file:
android:debuggable="true"
This flag disables SSL validation when going thru the hybrid channels and probably the reason why you don't see the SSL errors earlier. Direct update is handled at a different level, where this flag does not apply, and therefore SSL validation does occur.
You should use self-signed CA certificates instead for dev/test purposes. See the following answer on how to generate a self-signed CA:
https://stackoverflow.com/a/19841469/2494287
Direct update will not work with a self-signed certificate. It is intended to be used in production, therefore it will only accept a valid CA cert.