I'm leveraging the WePay node.js sdk https://github.com/wepay/NodeJS-SDK
When trying to communicate to WePay, I receive the error: Hostname/IP doesn't match certificate's altnames
This is running on Heroku and I have the SSL cert configured and it is valid for the domain that is making the request. I'm not sure if this is an issue on my end or if it is a config issue with Heroku.
Any insight would be appreciated.
Can you please specify the node version.Node 10.x has added security which can easy be disabled by rejectUnauthorized or process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0"; DONT DO IT!.
Better to add a CA in your list of CAs in http(s) global agent or in specifying ca:[cert] in http options where cert is the Certificate of CA or site you are connecting to.
Hope this helps.
Related
I have a nodejs application running on a container based on alpine 3.14. Due to the recent expiration of the Letsencrypt CA cert on Sept 30, it was unable to invoke an HTTPS endpoint via axios because of the expired CA cert as it was getting the error that the actual cert on the endpoint has expired, although the cert was valid.
I went through solutions posted online to overcome this issue. Particularly the solution mentioned here commenting DST_Root_CA_X3.crt from /etc/ca-certificates.conf this: https://stackoverflow.com/a/69408777/4178878
I get the error
"unable to get issuer certificate"
I also tried the solution highlighted as FIX on this answer that mentions about adding X1 and X2 and Intermediate R3: https://stackoverflow.com/a/69411107/4178878
Yet I get the same error
"unable to get issuer certificate"
Any inputs appreciated!
Need help!!! . I have an https request and need to intercept it, read values and forward the same ssl request to the destination. I have all the required crt, key, CA with me. I am aware that Haproxy ACL does not work with L4 layer but I'm trying to find a workaround to decrypt the message, read the message, encrypt it again and forward. The reason for reading message is to using ACL i need to read the path difference in carious request and route the request to different servers accordingly. I am trying to intercept the client request to server, the request by default is SSL and server is expecting an SSL request
ssl crt: created a new user with new crt-key pair and used Certificate Signing Requests of server to authenticate it against CA in server
The scenario is that I have an incoming SSL request which I'm capturing into frontend of haproxy with the server certificate, while forwarding that request to a test webserver I am able to see that it has changed from HTTPS to HTTP. Now when I try re-encrypt it, the original destination is not able to accept the request since it is not SSL, I have tried to add the certs in the backend but not useful. Please check my current Haproxy config and please help if possible. I am not an expert in Network communication/ Encryption/ HaProxy.
frontend test
bind IP:6443 ssl crt <location>
option httplog
mode http
default_backend testback
backend testback
mode http
balance roundrobin
option http-check
server <host> IP:6443 check fall 3 rise 2 ssl verify required ca-file <loc> crt <loc>
To verify my certicates are valid and connecting:
openssl s_client -connect :6443 -cert myuser.crt -key myuser.key -CAfile ca.crt
Output:
SSL handshake has read 1619 bytes and written 2239 bytes
Verification: OK
So no problem with Certicates i presume, problem while using Ha proxy for connection
Error:
Unable to connect to the server: x509: certificate specifies an incompatible key usage
Ha proxy error:
2021-08-12T14:45:36.930478+02:00 parasilo-27 haproxy[21562]: :34672 [12/Aug/2021:14:45:36.927] server/1: SSL handshake failure
2021-08-12T14:45:37+02:00 localhost haproxy[21562]: :34674 [12/Aug/2021:14:45:37.438] server/1: SSL handshake failure
To sum up what was analyzed in the comments, as asked. Perhaps it will be useful to somebody someday.
Haproxy's config turned out to be correct, but generated certificates had wrong extended key usage (X509v3 extension).
Command to list extended key usage:
openssl x509 -in /path/to/cert.pem -noout -ext extendedKeyUsage
Often, when bought on internet, it shows X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication. Original Poster used self-signed, self-generated certificates and his certificate used on haproxy's frontend had only TLS Web Client Authentication, where frontend requires TLS Web Server Authentication if this extensions is used at all.
That resulted in the error message:
Error: kubectl get po: Unable to connect to the server: x509: certificate specifies an incompatible key usage
As a consequence haproxy logged SSL handshake failure without any more details, as is its habit.
After adding TLS Web Server Authentication to certificate in haproxy's frontend section and TLS Web Client Authentication to certificate in haproxy's backend section Original Poster reported success.
My setup currently looks like:
API Gateway --- ALB --- ECS Cluster --- NodeJS Applications
|
-- Lambda
I also have a custom domain name set on API Gateway (UPDATE: I used the default API gateway link and got the same problem, I don't think this is a custom domain issue)
When 1 service in ECS cluster calls another service via API gateway, I get
Hostname/IP doesn't match certificate's altnames: "Host: someid.ap-southeast-1.elb.amazonaws.com. is not in the cert's altnames: DNS:*.execute-api.ap-southeast-1.amazonaws.com"
Why is this?
UPDATE
I notice when I start a local server that calls the API gateway I get a similar error:
{
"error": "Hostname/IP doesn't match certificate's altnames: \"Host: localhost. is not in the cert's altnames: DNS:*.execute-api.ap-southeast-1.amazonaws.com\""
}
And if I try to disable the HTTPS check:
const response = await axios({
method: req.method,
url,
baseURL,
params: req.params,
query: req.query,
data: body || req.body,
headers: req.headers,
httpsAgent: new https.Agent({
: false // <<=== HERE!
})
})
I get this instead ...
{
"message": "Forbidden"
}
When I call the underlying API gateway URL directly on Postman it works ... somehow it reminds me of CORS, where the server seems to be blocking my server either localhost or ECS/ELB from accessing my API gateway?
It maybe quite confusing so a summary of what I tried:
In the existing setup, services inside ECS may call another via API gateway. When that happens it fails because of the HTTPS error
To resolve it, I set rejectUnauthorized: false, but API gateway returns HTTP 403
When running on localhost, the error is similar
I tried calling ELB instead of API gateway, it works ...
There are various workarounds, which introduce security implications, instead of providing a proper solution. in order to fix it, you need to add a CNAME entry for someid.ap-southeast-1.elb.amazonaws.com. to the DNS (this entry might already exists) and also to one SSL certificate, alike it is being described in the AWS documentation for Adding an Alternate Domain Name. this can be done with the CloudFront console & ACM. the point is, that with the current certificate, that alternate (internal !!) host-name will never match the certificate, which only can cover a single IP - therefore it's much more of an infrastructural problem, than it would be a code problem.
When reviewing it once again... instead of extending the SSL certificate of the public-facing interface - a better solution might be to use a separate SSL certificate, for the communication in between the API Gateway and the ALB, according to this guide; even self-signed is possible in this case, because the certificate would never been accessed by any external client.
Concerning that HTTP403 the docs read:
You configured an AWS WAF web access control list (web ACL) to monitor requests to your Application Load Balancer and it blocked a request.
I hope this helps setting up end-to-end encryption, while only the one public-facing interface of the API gateway needs a CA certificate, for whatever internal communication, self-signed should suffice.
This article is about the difference in between ELB and ALB - while it might be worth a consideration, if indeed the most suitable load-balancer for the given scenario had been chosen. in case no content-based routing is required, cutting down on useless complexity might be helpful. this would eliminate the need to define the routing rules ...which you should also review once, in case sticking to ALB. I mean, the questions only shows the basic scenario and some code which fails, but not the routing rules.
I have a https client that is using ssl to connect to an apache server.
When the client try to connect to the apache server via https I got the following error:
SSL Library Error: 336151570 error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate Subject CN in certificate not server name or identical to CA!?
what could be the problem and how to solve it?
Subject CN in certificate not server name or identical to CA!?
Your certificate does not match the host nameyou access. Check your site against [SSLLabs](
https://www.ssllabs.com/ssltest/analyze.html).
I am trying to use the TLS module to perform an SSL connection to a server which happens to provide a wrong certificate (the hostname of server (xxx.example.com) does not match the common name of the certificate (yyy.example.com)).
I managed to get the client connecting without throwing an error by adding the option rejectUnauthorized: false.
However when the client is connected it is still unauthorized and the authorizationError is Hostname/IP doesn't match certificate's altnames.
How can I get around this? I obviously have no power on changing the server certificate (I did however contact them to try to get them amend the certificate).