I have created an http server to receive post-hooks from git whenever a push event is issued (for the purpose of auto-deployement).
The problem is that when I add a Web hook to my repository , and when an event is triggered, the request cannot reach the server.
And I get the following error:
We had a problem connecting to the server.
The most common problem with these types of errors is a misconfigured SSL Certificate .
Any ideas?
By default, a GitHub WebHook would perform SSL certificate verification
(and disabling that verification is not a good idea)
Make sure your server has all intermediate CAs in its keystore, and debug your certificate using an SSL checker as mentioned in "Troubleshooting GitHub WebHooks SSL Verification".
Related
I Need to attach a CA certificate with the postman request. I am attaching a CA certificate as shown in this in postman CA certifcate image. Here domain.pfx is not a self-signed certificate. It is signed by CA. When I attach this certifcate and hit the dotnet core web api controller, It is giving the socket hangup error. Its not even hitting dotnet core web api. Giving this error in postman.error_imageerror details.
But When I attach the self-signed certificate instead of a certificate signed by CA, everything works as expected. I can hit the controller and retrieve thumbprint from it. I am attaching the self-signed certificate in the same way.self-signed-certificate
I am getting the socket hangup error only when a CA certificate is attached, with Self-Signed certificate its working. How can I resolve this issue? Am I doing something wrong in adding CA certificate? Is there any other ways to attach a CA certificate in postman?
Your configuration of the certificate does not appear to be a problem. Since I don't know what your request looks like, I can only share with you a few cases where I encountered this error.
When you use same port for connecting database, which port is already in use for other service, then "Socket Hang up" error comes out. For example: port 51223 is dedicated port for some other service or connection. You cannot use same port (51223) for making a database connection on same server.
Your application was switched to https and your postman requests still had http in them. You can change postman to https to fix it.
Check if there is a VPN connection, if so, disconnect it.
Check if the version of postman is the latest version, this problem occurs in some versions.
Hope this can help you.
I create an API where I configure the endpoint: https://ssl.croinform.ru:450/api.test And there is a problem with https, I am not getting a response to the request. It seems the WSO2 API Manager API gateway is not proxying requests to the endpoint. When I make requests directly, I pre-configure the infrastructure: install the openssl counterpart, install the cacer.p7b and ssl.croinform.cer certificates. After that, I successfully receive responses from the ssl.croinform.ru:450/api.test service.
I was advised to add a certificate according to this manual: https://apim.docs.wso2.com/en/3.2.0/learn/design-api/endpoints/certificates/#adding-a-certificate-for-an-endpoint I did everything according to the manual, but requests to https are still not transmitted. The problem is I need to import two certificates: cacer.p7b, ssl.croinform.cer. I manage to add the .cer certificate, but the .p7b certificate is not added (I get an error), I suppose the .p7b file extension is simply not supported. But I need to transfer the whole certificate chain. Also, I do not understand how encryption is supported in wso2-am, but this is important, since traffic with a remote API is encrypted using tls. Am I getting it right that wso2-am works with openssl? If so, is it possible to use any other alternative software? In my case, openssl does not support some regional standards. I am still asking for hints or directions on my problem.
When I install a certificate with a .p7b extension in the portal I get the following error: The server encountered an internal error. Please contact administrator. The wso2carbon.log file contains the following events: ERROR {org.wso2.carbon.apimgt.impl.utils.CertificateMgtUtils} - Error loading certificate. java.security.cert.CertificateException: Unable to initialize, java.io.IOException: Short read of DER length at java.base / sun.security.x509.X509CertImpl. (X509CertImpl.java:197) at java.base / sun.security.provider.X509Factory.engineGenerateCertificate (X509Factory.java:10
Continuing: ERROR {org.wso2.carbon.apimgt.impl.certificatemgt.CertificateManagerImpl} - Error adding the certificate to Publisher Trust Store. Rolling back... ERROR {org.wso2.carbon.apimgt.impl.APIProviderImpl} - Adding certificate to the Publisher node is failed. No certificate changes will be affected. ERROR {org.wso2.carbon.apimgt.rest.api.publisher.v1.impl.EndpointCertificatesApiServiceImpl} - Error while adding the certificate due to an internal server error
Can you tell me what I need to do to make this work in WSO2 API Manager?
I have implemented a servlet to receive sms messages from Twilio; when someone replies to my twilio number. I have configured the server in twilio but I am getting ERROR 11220.
The servelet is in a AWS ec2 instance and is accessible via browser, JMeter. SSL Labs gave the servelet URL A+ rating. Not sure how come twilio can't reach it. I'm at a loss. Any tips on anything I can try would be greatly appreciated. Thanks.
TL/DR: Install (or have your server management company install) the full certificate chain that you got when you purchased the cert for your domain.
We ran into a similar issue with Twilio while using their faxing service; it gave the same error on callbacks.
More specifically, their event console (https://www.twilio.com/console/debugger) shows:
11200 - HTTP retrieval failure. In the details section it shows:
ErrorMessage: "Failed to fetch fax media from URL ... (Got status 502 trying to download media)"
Twilio_was_unable_to_fetch_content_from: ...
Error: _Connection_reset_by_peer_over_TLS, _assuming_that_this_is_a_handshake_failure
... SSL_Version:_TLSv1_2 URL_Fragment:_true
Twilio likely uses a Java library which, by default, has a set of certificates independent from the operating system's set of certificates.
All major browsers use their operating system's certificates, which is why you can see that the cert is valid in your browser. Services like SSL Labs that properly handle certs can also validate it.
Twilio could fix this by using their operating system's certificates or by keeping their certs up-to-date. Until such a time...
You have to work around the issue by installing the full certificate chain so that they can validate it. When you purchase a cert for your domain, they generally send the plain cert, as well as a full certificate chain bundle with all of the intermediate certificates. Installing the full chain should fix the issue.
I am trying to workout how to configure a CXF consumer to use https, but use basic authentication.
I presume we need to attach our certificate using the httpj:engine-factory but whenever I try and do that the server generated the follwing error:
javax.net.ssl.SSLHandshakeException: null cert chain
EDIT: I believe what is happening is that the server is requesting a client certificate, but the client does not send one. For "One Directional" SLL, I don't think the server should be asking for a certificate from the client.
How do I prevent the server from requesting a client certificate?
Any assistance greatly appreciated.
You need to install certificate in your JVM trust store. Please go through below link:
How to solve javax.net.ssl.SSLHandshakeException Error?
It turned out to be quite simple. In the httpj:engine-factory, there is a setting for client authentication.
<sec:clientAuthentication want="false" required="false"/>
This controls whether the server requests a certificate from the client. I had copied this from samples with Bi-Directional SSL and these values were set to true.
I'm have an application deployed to salesforce on the force.com platform,
which I'm trying to configure a 2 way SSL for.
I.e.
I want that for each request sent to from SF to my server, a client certificate will be sent.
I did the necessary configurations on SF for the certificate to be sent, but I'm still getting 403.7 from the server, which means: forbidden, client certificate required.
I installed wireshark on the server, captured traffic to see the 2 way ssl handshake, and I'm trying to find in the server hello message where it tells the client the trusted CAs from which a client certificate should correspond, but I'm having difficulties finding it.
I suspect that's why the client does not send the certificate.
Can anyone point me to where in the server hello I should look? Or perhaps in another packet capture?
Thanks in advance.
Client Key Exchange record:
Here, the server sends its Certificate Request message and the client sends its Certificate message in response, but that message contains 0 certificates.
Typically, this happens when the client was unable to select a client certificate to use. Either it's not configured properly to make use of any certificate, or it can't find one that is issued by one of the acceptable CAs.
Look at the Certificate Request packet and check its certificate_authorities list. This is a list of the CA Distinguished Names (DNs) that the server is willing to accept.
One way or another, the client will need to find a client certificate with which it can build a chain towards of those DNs. In the simplest case, a client certificate issued by such a DN is available. Otherwise, the client could have to build a chain from a client cert to such a DN, it would need to have the necessary intermediate CA certificates to do so. (How this is done depends on the client's configuration mechanisms.)
If intermediate CA certificates are necessary and not available on the client side, you may need to configure your server to accept them and advertise them in the Certificate Request too.
Added a screenshot of the handshake captures. can you please point me to where I should be looking? –
See packet #31. It contains the Certificate Request. Also packet #33 contains the certificate from the client, so the reason is not the client does not send the certificate, but instead that the server either does not like the certificate because the validation failed or because the certificate is not sufficient as authorization for the requested resource. You might get more information from the servers log.
Not sure if this will help anyone else, but for our case of this issue everything was working when running locally in Visual Studio and in IIS, but when deployed to a real server, we were hitting a certificate issue during 2-way SSL as described above and verified in Wireshark.
Anyway, on that server we have also have a .NET 4.7.2 Console application which was calling the same API and everything was working fine.
But, our .NET 4.7.2 web API calls were failing. It appears that when the same code was running inside IIS the cert was not available during the SSL negotiation. (although it loaded fine)
Our solution at this point was to modify the following call to include the 3rd parameter.
certificate = new X509Certificate2(certificatepath, Password, X509KeyStorageFlags.MachineKeySet);
By default X509Certificate2 uses the UserKeySet option, so perhaps the application pool user or another thread in IIS (?) was having trouble accessing the cert for the negotiation.
Here are a couple of the related pages that I found useful during my research:
https://paulstovell.com/x509certificate2/
https://github.com/dotnet/runtime/issues/23437