I'm developing an API with NodeJS, and I've recently updated the certificate. The certificate is valid, but my API shows me an error saying that the certificate is not valid while at the same time it shows the right expiration date.
{ daysRemaining: 32,
valid: false,
validFrom: '2021-07-12T08:50:22.000Z',
validTo: '2021-10-10T08:50:21.000Z',
validFor: [ '*.domain.com' ] }
Environment:
My API is in an Ubuntu Docker container
NodeJS version: v10.19.0
Certificate: Let's Encrypt
What I tried:
I've checked the date of my server and it's valid.
I also tried to clean the server's cache.
I've updated nodeJS.
The weird part is that when I call my API sometimes it works and sometimes it says the certificate has expired.
If someone has had the same issue or has an idea how to fix it, I would be so thankful.
Related
TLDR:
Can't post to local Cosmos Emulator. Can post to Azure Cosmos, but not with #azure/cosmos-sign, only with #azure/cosmos (which seems utterly bizare as the latter is supposedly built upon the former.) This is not ideal (as the message signing portion alone is very lightweight with REST API directly). Bug, or user error? Why do the instructions for enabling networking/https not seem to work?
Details:
I have a Node.js based app, and am using the Azure/cosmos-sign package to generate the correct headers via the generateHeaders method to save a JSON object in the local Cosmos Emulator.
Upon trying to post from the Node app to the URI provided in the Emulator Quickstart (https://localhost:8081), the error returned is...
Error: connect ECONNREFUSED 127.0.0.1:8081 : https://localhost:8081
As per these instructions...
Enable access to emulator on a local network
If you have multiple machines using a single network, and if you set
up the emulator on one machine and want to access it from other
machine. In such case, you need to enable access to the emulator on a
local network.
You can run the emulator on a local network. To enable network access,
specify the /AllowNetworkAccess option at the command-line, which
also requires that you specify /Key=key_string or
/KeyFile=file_name. You can use /GenKeyFile=file_name to generate
a file with a random key upfront. Then you can pass that to
/KeyFile=file_name or /Key=contents_of_file.
To enable network access for the first time, the user should shut down
the emulator and delete the emulator's data directory
%LOCALAPPDATA%\CosmosDBEmulator.
-https://learn.microsoft.com/en-us/azure/cosmos-db/local-emulator?tabs=cli%2Cssl-netstd21#enable-access-to-emulator-on-a-local-network
...I thought perhaps I needed to enable the networking functionality. It is all on the same (Windows) host (with the Node.js application running in Docker on the same host as the Emulator is installed). But this caused more problems with no benefit. With the generated key, I can load the included UI for managing the local emulator instance, but I then can't create Databases or Containers (without resetting the emulator and starting it again normally, eg: without the AllowNetworkAccess and related settings).
Attempting to use the included Explorer to create a Database returns...
Error while creating database SampleDb:
{
"code": 401,
"body": {
"code": "Unauthorized",
"message": "The input authorization token can't serve the request. Please check that the expected payload is built as per the protocol, and check the key being used. Server used the following payload to sign: 'post\ndbs\n\nmon, 29 mar 2021 23:33:45 gmt\n\n'\r\nActivityId: 29e4e700-d1b7-4d59-bdea-5931e4d6622d, Microsoft.Azure.Documents.Common/2.11.0"
},
"headers": {
"access-control-allow-credentials": "true",
"access-control-allow-origin": "https://localhost:8081",
"access-control-expose-headers": "Access-Control-Allow-Origin,Access-Control-Allow-Credentials,Content-Type,x-ms-activity-id,x-ms-gatewayversion",
"content-type": "application/json",
"date": "Mon, 29 Mar 2021 23:33:45 GMT",
"server": "Microsoft-HTTPAPI/2.0",
"x-firefox-spdy": "h2",
"x-ms-activity-id": "29e4e700-d1b7-4d59-bdea-5931e4d6622d",
"x-ms-gatewayversion": "version=2.11.0",
"x-ms-throttle-retry-count": 0,
"x-ms-throttle-retry-wait-time-ms": 0
},
"activityId": "29e4e700-d1b7-4d59-bdea-5931e4d6622d"
}
I did see this somewhat similar SO question, but it was abandoned.
This one, however seems to imply they simply reverted the KeyFile steps mentioned in the MS Docs. It seems odd that I am getting the same error from the Node.js POST regardless of if I use the AllowNetworkAccess switch or not.
Using the /NoFirewall switch as recommended here didnt resolve POSTs but did allow the Explorer UI to still work properly. The upvoted answer for that question is what I have already tried (/AllowNetworkAccess /KeyFile=...., and is not working, as explained above).
The docs here indicate that TLS (https) is in fact required...
"The Azure Cosmos DB Emulator supports only secure communication via TLS"
However, here they seem to indicate that, in the Node SDK (which relies on the same cosmos-sign library I am using)...
"TLS verification is disabled. By default the Node.js SDK(version 1.10.1 or higher) for the SQL API will not try to use the TLS/SSL certificate when connecting to the local emulator."
I tried adjusting the start script for my Node Docker image as suggested here...
If connecting to the Cosmos DB Emulator, disable TLS verification
for your node process:
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
const client = new CosmosClient({ endpoint, key });
...and changed the start script in my package.json from...
"start": "node $NODE_OPTIONS node_modules...."
...to...
"start": "NODE_TLS_REJECT_UNAUTHORIZED=0 node $NODE_OPTIONS node_modules...."
...and rebuilt my images, but still receive the same ECONNREFUSED error from the Node client/app.
As I was reading the documentation for the REST API I was reminded that, as opposed to using the CosmosClient (which just needs the base URL), to do a post to the API the url needs to be fully formed as indicated here...
Method: POST
Request URI: https://{databaseaccount}.documents.azure.com/dbs/{db-id}/colls/{coll-id}/docs
Description: The {databaseaccount} is the name of the Azure Cosmos DB account created under your subscription. The {db-id} value is the
user generated name/ID of the database, not the system generated ID
(rid). The {coll-id} value is the name of the collection that contains
the document.
After appending /dbs/SampleDB/colls/SampleCollection/docs (yes, my entities are CamelCase) to the base url offered by the Emulator UI's Quickstart URI (https://localhost:8081)... I am still getting the ECONNREFUSED error to http posts.
Hmm... retargeted the Node app to point to a collection in my Azure Cosmos DB, and I am still having no luck.
400: Invalid API version. Ensure a valid x-ms-version header value is
passed. Please update to the latest version of Azure Cosmos DB
SDK.ActivityId: bfdeb339-8fef-4ba9-a03d-444a8664c02b,
Microsoft.Azure.Documents.Common/2.11.0
Added x-ms-version and set it to 2018-12-31 (latest, as per here).
Now I am getting (after trying both my secondary, and primary keys... just in case)...
401: The input authorization token can't serve the request. Please
check that the expected payload is built as per the protocol, and
check the key being used. Server used the following payload to sign:
'postdocsdbs/TopHand/colls/SampleTbltue, 30 mar 2021 02:54:25
gmt'ActivityId: bb258bb4-f5a8-4495-b0b5-b54fa8b7c46f,
Microsoft.Azure.Documents.Common/2.11.0
I verified that the required headers are all present. What can possibly be left?!
Base URI for Azure Cosmos had a trailing /, which ended up duplicated when the rest of the path was appended. Fixing the url string, still getting the 401.
A github issue pointed me to what may have been an error in the URL/REST path I was posting to. Rather than posting to (what I had previously)...
dbs/SampleDb/colls/SampleTbl/docs
...I changed it to...
dbs/SampleDb/colls/SampleTbl
...and am now getting error 405, MethodNotAllowed, RequestHandler.Post. 405 isn't listed as code returned by the Cosmos REST service.
This example in the MS docs definitely uses the /docs string at the end of the url/REST path.
Example
POST https://querydemo.documents.azure.com/dbs/1KtjAA==/colls/1KtjAImkcgw=/docs HTTP/1.1
x-ms-documentdb-partitionkey: ["Andersen"]
x-ms-date: Tue, 29 Mar 2016 02:28:29 GMT
authorization: type%3dmaster%26ver%3d1.0%26sig%3d92WMAkQv0Zu35zpKZD%2bcGSH%2b2SXd8HGxHIvJgxhO6%2fs%3d
Cache-Control: no-cache
User-Agent: Microsoft.Azure.Documents.Client/1.6.0.0
x-ms-version: 2015-12-16
Accept: application/json
Host: querydemo.documents.azure.com
Cookie: x-ms-session-token#0=602; x-ms-session-token=602
Content-Length: 344
Expect: 100-continue
{
"id": "AndersenFamily",
"LastName": "Andersen",
}
I contacted MS support and was giving some info that unblocked me (but doesn't entirely address the issues noted above).
For my own use-case, simply setting a key and allowing network access to the emulator was sufficient.
Note: This doesn't address the issues of the Emulator's Data Explorer becoming nonfunctional.
The feedback I received from the support personnel in regard to using the command line switches disabling the UI was...
By changing the key to something other than default one, you also
protect your emulator data from being seen via the Data Explorer.
Apparently the key alone isn't enough to protect the data, and disabling the UI is a "feature".
Solution: Simply executing...
.\Microsoft.Azure.Cosmos.Emulator.exe /AllowNetworkAccess /Key={insert your base64 encoded 64+ character string}
...allowed network access to systems on the same host as the emulator. This avoided all the certificate/key generation/importing/etc headache.
You must connect to the non-loopback IP of the host the emulator is running on to connect to it (writes/reads/etc).
I have already checked this post. But even though I tried that method, it didn't work, so I open a new issue.
I use AWS EC2 server and deploy with aws pipeline. So When I push to github repository, it will automatically build and deploy to production server.
At first it's works fine, and there are no errors in the console.
But one day an error began to occur. So when I checked the console, there was an error as below.
[Error Message in console]
set greenlockOptions.notify to override the default logger
certificate_order (more info available: account subject altnames challengeTypes)
Error cert_issue:
[acme-v2.js] authorizations were not fetched for 'mydomain.com':
{"type":"urn:ietf:params:acme:error:rateLimited","detail":"Error creating new order :: too many certificates already issued for exact set of domains: mydomain.com: see https://letsencrypt.org/docs/rate-limits/","status":429,"_identifiers":[{"type":"dns","value":"mydomain.com"}]}
Error: [acme-v2.js] authorizations were not fetched for 'mydomain.com':
{"type":"urn:ietf:params:acme:error:rateLimited","detail":"Error creating new order :: too many certificates already issued for exact set of domains: mydomain.com: see https://letsencrypt.org/docs/rate-limits/","status":429,"_identifiers":[{"type":"dns","value":"mydomain.com"}]}
at Object.E.NO_AUTHORIZATIONS (/home/project/build/node_modules/#root/acme/errors.js:75:9)
at /home/project/build/node_modules/#root/acme/acme.js:1198:11
at processTicksAndRejections (internal/process/task_queues.js:97:5)
Error cert_issue:
[acme-v2.js] authorizations were not fetched for 'mydomain.com':
In my opinion, I think there was a limit to the process of reissuing the certificate every time I push the code, but I don't know where the problem occurred even if I check the code.
My code structure is written as below and developed with Express.
[server.js]
"use strict";
const app = require("./app.js");
require("greenlock-express")
.init({
packageRoot: __dirname,
configDir: "./greenlock.d",
// contact for security and critical bug notices
maintainerEmail: process.env.EMAIL,
// whether or not to run at cloudscale
cluster: false
})
// Serves on 80 and 443
// Get's SSL certificates magically!
.serve(app);
[greenlock.d/config.json]
{ "sites": [{ "subject": "mydomain.com", "altnames": ["mydomain.com"] }] }
[.greenlockrc]
{"configDir":"./greenlock.d"}
[package.json (scripts.start line)]
"scripts": {
"start": "node server.js"
},
I am aware of the seven-day limit from Let's Encrypt. So I want to find a way to solve this problem.
in my express folder, I do
sudo chmod 775 ./greenlock.d
then I delete greenlock.d(one time) and npm start
I dont have issue since
I am using the request library to fetch a response from an API, everything was working fine but as of recent, I have started to get local issuer certificate error from the API although the same code is working on my colleague's system.
I have already tried updating the node version and all the version changes regarding the request package of node
The exact error is:
unable to get local issuer certificate node
Here is the error snippet in the console
Could u please console only response..After that u can easily see that there is statusCode is available or not.
Or if u get the statusCode then check its defined or not.
Ex: if(res.statusCode)
console.log("print status code", this.res.statusCode);
This is an SSL error and yo need to make sure that your server's certificate is valid.
With your claim that it used to work - but it stopped working recently with the SSL error message, the possibilities are that either your servers certificate is expired in between or the Sectigo AddTrust External CA Root Expiring May 30, 2020.
https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA03l00000117LT
Updating the certificate is outside the scope of this answer. You may have to do it yourself or contact the admin.
I'm trying to run example Jira add-on.
I have created credentials.json file and have run npm i and node app.js.
But I have problems with installed event. Here is nodejs log:
Watching atlassian-connect.json for changes
Add-on server running at http://MacBook-Air.local:3000
Initialized sqlite3 storage adapter
Local tunnel established at https://a277dbdf.ngrok.io/
Check http://127.0.0.1:4040 for tunnel status
Registering add-on...
GET /atlassian-connect.json 200 13.677 ms - 784
Saved tenant details for 608ff294-74b9-3edf-8124-7efae2c16397 to database
{ key: 'my-add-on',
clientKey: '608ff294-74b9-3edf-8124-7efae2c16397',
publicKey: 'MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtKxrEBipTMXhRHlv9zcSLR2Y9h5YQgNQ5vpJ40tF9RmuIzByjkKTurCLHFwMAWU6aLQM+H+Z8wAlpL9AVlN5NKrEP8+a3mGFUOj/5nSJ7ZWHjgju0sqUruyEkKLvKuhWkKkd9NqBxogN0hxv7ue5msP5ezwei/nTJXmnmA5qOAQIDAQAB',
sharedSecret: 'LfT9elHM7iHkto5pHr+MnpH0SR1ypunIDoCyt6ugVJ1Q4hWHurG8k5DjVzLcvT2C98DDbiJiA89VNB0e3DiUvQ',
serverVersion: '100075',
pluginsVersion: '1.3.407',
baseUrl: 'https://gleb-olololololo-22.atlassian.net',
productType: 'jira',
description: 'Atlassian JIRA at https://gleb-olololololo-22.atlassian.net ',
eventType: 'installed' }
POST /installed?user_key=admin 204 51.021 ms - -
Failed to register with host https://gleb-olololololo-22%40yopmail.com:gleb-olololololo-22#gleb-olololololo-22.atlassian.net (200)
The add-on host did not respond when we tried to contact it at "https://a277dbdf.ngrok.io/installed" during installation (the attempt timed out). Please try again later or contact the add-on vendor.
{"type":"INSTALL","pingAfter":300,"status":{"done":true,"statusCode":200,"contentType":"application/vnd.atl.plugins.task.install.err+json","errorMessage":"The add-on host did not respond when we tried to contact it at \"https://a277dbdf.ngrok.io/installed\" during installation (the attempt timed out). Please try again later or contact the add-on vendor.","source":"https://a277dbdf.ngrok.io/atlassian-connect.json","name":"https://a277dbdf.ngrok.io/atlassian-connect.json"},"links":{"self":"/rest/plugins/1.0/pending/80928cb9-f64e-42d0-9a7e-a1fe8ba81055","alternate":"/rest/plugins/1.0/tasks/80928cb9-f64e-42d0-9a7e-a1fe8ba81055"},"timestamp":1513692335651,"userKey":"admin","id":"80928cb9-f64e-42d0-9a7e-a1fe8ba81055"}
Add-on not registered; no compatible hosts detected
I have reviewed tons of information in Google, but didn't found an answer.
More details, that can helps you to answer.
It happens suddenly. It worked OK, but about 1 week ago I start to get this error and cannot fix it. So I didn't change anything, just run add-on again, as I did it every day.
If I try to upload add-on manually I got error in terminal
GET / 302 17.224 ms - 0
GET /atlassian-connect.json 200 2.503 ms - 783
Found existing settings for client 608ff294-74b9-3edf-8124-7efae2c16397. Authenticating reinstall request
Authentication verification error: 401 Could not find authentication data on request
POST /installed?user_key=admin 401 22.636 ms - 45
The most possible reason (that I've found in google) is that I have wrong server time. But the time on my local machine is correct (at least for my timezone).
Anyone has any thoughts about this problem?
Thanks!
I kept randomly having this happen to me. It would be working, then run npm start and I would get the error. Since I'm not using a database right now, I simply removed all references to the juggling-sqlite database. This was in package.json, package-lock.json, config.json, and I just removed store.db. That got it working for me. Pretty frustrating that this happens, not sure a better way around it.
I have installed node.js server on shared hosting.I have drupal site in which I am using node.js integration module to connect to node.js server.
But whenever I am trying to broadcast message from admin panel, I am getting this error message "Error reaching the Node.js server "Error reaching the Node.js server at "nodejs/publish" with {"data":{"somecustomdata":"http://www.google.ca"},"channel":"nodejs_user_1","callback":"myowncallback","clientSocketId":""} "%{"data":{"somecustomdata":"http://www.google.ca"},"channel":"nodejs_user_1","callback":"myowncallback","clientSocketId":""}": [404] Not Found." in db log.
Any help would be appreciated.
It is very likely one of two things:
Drupal server is accessing wrong URI.
Node.js Server is not listening to the URI you expect it to.
Of course something less obvious might cause errors, but please verify those two before proceeding.
Best would be to get your Drupal server print in error logs the URI it is trying to access, and manually verify you can access it within your browser, or another tool.
Thanks "alandrev" for your help.I have resolved that issue on the same day but I forgot to add my mistake.Actually I was not configuring the nodejs correctly.I was using the incorrect port number on backend settings in nodejs.config.js file.The correct settings mentioned below:
backendSettings = {
"scheme":"https",
"host":"yourhostname",
"port":"port number which is not already in use",
'sslKeyPath': 'key file path for ssl enabled site otherwise leave empty',
'sslCertPath': 'certificate path for ssl enabled site otherwise leave empty',
'sslCAPath': '',
"resource":"/socket.io",
"baseAuthPath": '/nodejs/',
"publishUrl":"publish",
"serviceKey":"",
"backend":{
"port":443,
"scheme": 'https or http',
"host":"yourhostname",
"messagePath":"/nodejs/message/"},
"clientsCanWriteToChannels":false,
"clientsCanWriteToClients":false,
"extensions":"",
"debug":false,
"addUserToChannelUrl": 'user/channel/add/:channel/:uid',
"publishMessageToContentChannelUrl": 'content/token/message',
"jsMinification":true,
"jsEtag":true,
"logLevel":1};
Solved this same issue by adding "polling" to the transport
backendSettings = {
"scheme":"http",
"host":"localhost",
"port":8081,
"key":"/path/to/key/file",
"cert":"/path/to/cert/file",
"resource":"/socket.io",
"publishUrl":"publish",
"serviceKey":"SERVICE KEY",
"backend":{
"port":80,
"host":"localhost",
"messagePath":"/mysite/nodejs/message/"},
"clientsCanWriteToChannels":true,
"clientsCanWriteToClients":true,
"extensions":"",
"debug":true,
"transports":["websocket","polling",
"flashsocket",
"htmlfile",
"xhr-polling",
"jsonp-polling"],
"jsMinification":true,
"jsEtag":true,
"logLevel":1};