Hostname/IP does not match certificate's altnames

[ehamery]

await connex.thor.transaction(transactionId).get();

sometimes give me:

Error: get transactions/0x70bcdc3f..fb6c7c13: Hostname/IP does not match certificate's altnames: Host: vethor-node.vechain.com. is not in the cert's altnames: DNS:*.facebook.com, DNS:*.facebook.net, DNS:*.fbcdn.net, DNS:*.fbsbx.com, DNS:*.m.facebook.com, DNS:*.messenger.com, DNS:*.xx.fbcdn.net, DNS:*.xy.fbcdn.net, DNS:*.xz.fbcdn.net, DNS:facebook.com, DNS:messenger.com

Any idea why?

[libotony]

To diagnose the issue could you try curl -vvv https://vethor-node.vechain.com/transactsions/{tx_id} and paste the response here.
Also you can try other public nodes listed here https://docs.vechain.org/others/development-resources.html#public-nodes

[ehamery]

I did not keep the whole transaction ID because it is not specific to that transaction, it happens once in a while on different transactions.

[libotony]

Any transaction ID is fine for debugging the issue.

[ehamery]

$ curl -vvv https://vethor-node.vechain.com/transactions/0xab5e6f13f9ae28e5d7bbc11058280a9906ac29091398402302b85b732a6fb583
*   Trying 128.1.34.13:443...
* Connected to vethor-node.vechain.com (128.1.34.13) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=*.vechain.com
*  start date: Apr  8 00:00:00 2020 GMT
*  expire date: May  8 23:59:59 2022 GMT
*  subjectAltName: host "vethor-node.vechain.com" matched cert's "*.vechain.com"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
> GET /transactions/0xab5e6f13f9ae28e5d7bbc11058280a9906ac29091398402302b85b732a6fb583 HTTP/1.1
> Host: vethor-node.vechain.com
> User-Agent: curl/7.77.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Vary: Accept-Encoding
< X-Genesis-Id: 0x00000000851caf3cfdb6e899cf5958bfb1ac3413d346d43539627e6be7ec1b4a
< X-Thorest-Ver: 1.4.0
< Date: Thu, 05 May 2022 01:51:04 GMT
< Content-Length: 542
< 
{"id":"0xab5e6f13f9ae28e5d7bbc11058280a9906ac29091398402302b85b732a6fb583","chainTag":74,"blockRef":"0x00b8ed749eed5080","expiration":18,"clauses":[{"to":"0x45d1409d5860787611fdd77bfdd06e506aa0cd74","value":"0x29bb4b661bcb6540000","data":"0x"}],"gasPriceCoef":0,"gas":21000,"origin":"0x807a0ac661f2044b93724224fa74e5224b86dd44","delegator":null,"nonce":"0x62293c12b05f5df6","dependsOn":null,"size":129,"meta":{"blockID":"0x00b8ed76810632eb297749c6a727a292d939d51d67331fa9bb5d37f6284a0e7a","blockNumber":12119414,"blockTimestamp":1651715330}}
* Connection #0 to host vethor-node.vechain.com left intact

[libotony]

$ curl -vvv https://vethor-node.vechain.com/transactions/0xab5e6f13f9ae28e5d7bbc11058280a9906ac29091398402302b85b732a6fb583
*   Trying 128.1.34.13:443...
* Connected to vethor-node.vechain.com (128.1.34.13) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=*.vechain.com
*  start date: Apr  8 00:00:00 2020 GMT
*  expire date: May  8 23:59:59 2022 GMT
*  subjectAltName: host "vethor-node.vechain.com" matched cert's "*.vechain.com"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
> GET /transactions/0xab5e6f13f9ae28e5d7bbc11058280a9906ac29091398402302b85b732a6fb583 HTTP/1.1
> Host: vethor-node.vechain.com
> User-Agent: curl/7.77.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Vary: Accept-Encoding
< X-Genesis-Id: 0x00000000851caf3cfdb6e899cf5958bfb1ac3413d346d43539627e6be7ec1b4a
< X-Thorest-Ver: 1.4.0
< Date: Thu, 05 May 2022 01:51:04 GMT
< Content-Length: 542
< 
{"id":"0xab5e6f13f9ae28e5d7bbc11058280a9906ac29091398402302b85b732a6fb583","chainTag":74,"blockRef":"0x00b8ed749eed5080","expiration":18,"clauses":[{"to":"0x45d1409d5860787611fdd77bfdd06e506aa0cd74","value":"0x29bb4b661bcb6540000","data":"0x"}],"gasPriceCoef":0,"gas":21000,"origin":"0x807a0ac661f2044b93724224fa74e5224b86dd44","delegator":null,"nonce":"0x62293c12b05f5df6","dependsOn":null,"size":129,"meta":{"blockID":"0x00b8ed76810632eb297749c6a727a292d939d51d67331fa9bb5d37f6284a0e7a","blockNumber":12119414,"blockTimestamp":1651715330}}
* Connection #0 to host vethor-node.vechain.com left intact

This seems no problem. Maybe do a diagnosis when you got the same problem.

[ehamery]

How do I do a "diagnosis"?

[libotony]

It's a connection issue, depends on your network setup, the public node setup. curl -vvv is the way to do the diagnosis.

[ehamery]

This seems no problem. Maybe do a diagnosis when you got the same problem.

Of course there is no problem here, as I said above it happens once in a while on different transactions and here the error did not occur. So when the error does not occur, yes there is no problem...

[ehamery]

It's a connection issue, depends on your network setup, the public node setup. curl -vvv is the way to do the diagnosis.

How can you say that without reproducing the error? It is likely that just running the curl command will never produce the error if the issue is in the connex package...

[libotony]

How can you say that without reproducing the error?

It's my opinion on this issue, based on my experience, the error was encountered during HTTP request. I tried locally, it does not produce the same error, are you having the same issue every time you try to get a transaction?

[ehamery]

I did not keep the whole transaction ID because it is not specific to that transaction, it happens once in a while on different transactions.

So the answer is no, the error deos not happen every time I try to get a transaction.