You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is no problem with using acme.sh (it is really easy to use), but I found a phenomenon, because it is beyond my knowledge, I don't know if it is a bug or something else, I will share it here and hope that people who understand can Improve it (if it's a bug)
Allow me to start with a description of the problem:
During the connection between the openvpn server (2.4.x) and the client (2.4.x), I tried all the public CA certificate stores in acme.sh!
It is found that the client cannot connect to the server. I have tried various RSA/ECDSA algorithms, and they are all the same. I havetily attributed the problem to the CA, please see here
The openvpn Windows client reported such an error during the connection process. (Originally, I was operating on two servers, using the verb 4 level log, and these error messages were not displayed. )Following these error messages, I followed the clues and found identified the problem and finally provided workaround (That is, use a third-party certificate chain repair tool to repair the fullchain ).and you will find the repaired new certificate chain The third paragraph is different!
Fri May 20 16:49:40 2022 VERIFY ERROR: depth=1, error=unable to get issuer certificate: C=US, O=Let's Encrypt, CN=R3, serial=192961496339968674994309121183282847578
Fri May 20 16:49:40 2022 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Fri May 20 16:49:40 2022 TLS_ERROR: BIO read tls_read_plaintext error
Fri May 20 16:49:40 2022 TLS Error: TLS object -> incoming plaintext read error
Fri May 20 16:49:40 2022 TLS Error: TLS handshake failed
The following is the real certificate I provided, in order to facilitate the search for the problem!
The final problem is that the top-level CA of the certificate or certificate chain issued by acme.sh is not the same as the top-level CA of the third-party tool to repair the certificate chain. Do you have any thoughts and suggestions on this? Welcome to popularize science for me or eliminate me , although I solved the problem, but I don't know why!
That is to say, the certificate issued by acme.sh cannot directly fill the CA content into the [CA field] of the openvpn server/client, because the TLS verification of openvpn cannot obtain the top-level CA. According to the above error message, I checked the Google The problem is that we need to repair the certificate chain by ourselves, so that the third part of the certificate chain is regarded as a CA and filled in the [CA field] of openvpn.
Although the default certificate chain can be used in browsers without problems, openvpn cannot be used directly! So I hope to improve it. Because openvpn is indeed a very useful tool
Also, if there is a problem with using openvpn, I can share and help troubleshoot and solve the problem, I'm fairly thorough with openvpn, at least for maximum security, I've spent a lot of time researching and learning to use it!
The text was updated successfully, but these errors were encountered:
There is no problem with using acme.sh (it is really easy to use), but I found a phenomenon, because it is beyond my knowledge, I don't know if it is a bug or something else, I will share it here and hope that people who understand can Improve it (if it's a bug)
Allow me to start with a description of the problem:
During the connection between the openvpn server (2.4.x) and the client (2.4.x), I tried all the public CA certificate stores in acme.sh!
It is found that the client cannot connect to the server. I have tried various RSA/ECDSA algorithms, and they are all the same. I havetily attributed the problem to the CA, please see here
The openvpn Windows client reported such an error during the connection process. (Originally, I was operating on two servers, using the verb 4 level log, and these error messages were not displayed. )Following these error messages, I followed the clues and found identified the problem and finally provided workaround (That is, use a third-party certificate chain repair tool to repair the fullchain ).and you will find the repaired new certificate chain The third paragraph is different!
The following is the real certificate I provided, in order to facilitate the search for the problem!
The final problem is that the top-level CA of the certificate or certificate chain issued by acme.sh is not the same as the top-level CA of the third-party tool to repair the certificate chain. Do you have any thoughts and suggestions on this? Welcome to popularize science for me or eliminate me , although I solved the problem, but I don't know why!
fullchain.cer
cert.cer
ca.cer
Use third-party tools to obtain certificate chains
wrong fullchain:
after repair fullchain
summary of a problem:
That is to say, the certificate issued by acme.sh cannot directly fill the CA content into the [CA field] of the openvpn server/client, because the TLS verification of openvpn cannot obtain the top-level CA. According to the above error message, I checked the Google The problem is that we need to repair the certificate chain by ourselves, so that the third part of the certificate chain is regarded as a CA and filled in the [CA field] of openvpn.
Although the default certificate chain can be used in browsers without problems, openvpn cannot be used directly! So I hope to improve it. Because openvpn is indeed a very useful tool
The text was updated successfully, but these errors were encountered: