Azure PostgreSQL does NOT care about certificate? - node.js

My pg flexible server at Azure already has the following SSL parameters set:
According to MS Doc it is supposed to reject any request without a valid certificate. But this nodejs connection string from my local VSC F5 always works regardless whether the supplying .pem file exists or not.
const conn = "postgres://" + process.env.PGuser
+":" + process.env.PGpassword
+ "#my-pg-flexsvr-test.postgres.database.azure.com/"
+ process.env.PGdatabase
+ "?sslmode=verify-all?sslrootcert=./environment/NoSuchFile.crt.pem";
Tested with psql found:
run the default runpsql.bat which does not ask for certificate and SSLMode, always works when username/password are correct.
when providing sslmode and sslrootcert, they must be valid, for example: C:\Program Files\PostgreSQL\12\scripts>psql "sslmode=verify-full sslrootcert=C:\\Users\\me\\DigiCertGlobalRootCA.crt.pem host=my-pg-flexsrv-test.postgres.database.azure.com dbname=mydb user=myuser
Seems AZ pg doesn't care about your certificate if not supplied or exists.
Local system:
VSC: 1.63.1 (system setup)
Date: 2021-12-14T02:13:54.292Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19044

Related

Node.js crypto fails to sign pem key string from file with error:25066067:DSO support routines:dlfcn_load:could not load the shared library

I have two node projects running side by side in my Git directory.
Same version of node 14.5, same pem key in root, same everything. Yet, one node process is able to sign my base64 pem key and the other is not. I can remove the base64 setting and still one process signs, the other doesn't.
I get this error message from the sign.sign() method.
error:25066067:DSO support routines:dlfcn_load:could not load the shared library
The code is as follows:
const crypto = require('crypto');
var policy = {
Statement: [
{
Resource: 'https://dev.geolytix.io/mapp/workspace.json',
Condition: { DateLessThan: { 'AWS:EpochTime': Date.now() + 60 * 60 * 1000 } },
},
],
};
var sign = crypto.createSign('RSA-SHA1');
sign.write(JSON.stringify(policy));
var pem = String(readFileSync(join(__dirname, `./mykey.pem`)))
let signature = sign.sign(pem, 'base64')
I noticed the problem occuring after updating my OS to Ubuntu 22.04.
I have purged openssl (version 3) and manually installed openssl 1.1.1o from source. https://fedingo.com/how-to-install-openssl-in-ubuntu/
Unfortunately that will remove other apps like Chrome which require a newer version of OpenSSL.
I was now able to manually build and install openssl 3.0.3. The crypto module still fails.
As a quick fix, run:
export OPENSSL_CONF=/dev/null
Alternatively, upgrade your node to at least v18.x.
Both answers are taken from the comments. What I really wanted to add is how to set the OPENSSL_CONF in Heroku environments. In your app Settings, under "Config Vars" do:
Please downgrade your Ubuntu version from 22.XX to 21.XX or lower.

Loading npm registry ca certs from environment to npmrc

In order to use private npm registry I am trying to setup credentials and ca certs in project's .npmrc file .
like following:
ca[]=<ROOT_CA> # NOTE this needs to string in double quotes, with newlines replaced be \n
ca[]=<INTERMEDIATE_CA> # NOTE this needs to string in double quotes, with newlines replaced be \n
And it works absolutely fine.
But when I move these values to system environment (Mac OS .zshrc) & try to read like following :
ca[]="${NPM_REG_ROOT_CERT}"
ca[]="${NPM_REG_INTERMEDIATE_CERT}"
It gives me error like following
npm ERR! code UNABLE_TO_VERIFY_LEAF_SIGNATURE
npm ERR! errno UNABLE_TO_VERIFY_LEAF_SIGNATURE
npm ERR! request <complete path to dependency> failed, reason: unable to verify the first certificate
I have ensured the env values are available & everything works fine (other login credentials are also coming from environment only).
These CA certs are having issue while loading from system environment !
If I disable strict-ssl things work. It means other credentials are loading correctly from system environment .
Am I missing something here ?
Could it be related to format of CA cert string stored in system environment. I am setting it as base64 string having newline replaced with \n.
Please help.

ReplyError: ERR invalid expire time in set - redis - Node.js

I have a Node.js web application which uses redis as session storage. Some requests receive the following ReplyError while trying to save the session:
ReplyError: ERR invalid expire time in set
at parseError (.../node_modules/redis-parser/lib/parser.js:179:12)
at parseType (.../node_modules/redis-parser/lib/parser.js:302:14)
I checked the specified file but I couldn't find anything which might cause it. Also, as far as I know, set method doesn't receive a expire time argument. I would very much appreciate any pointers as to how to fix it or what may cause it.
OS: Ubuntu 18.04.5 LTS
NodeJS version: 12.19.0
redis-server version: 4.0.9
node-redis version: 3.0.2
node-redis-parser version: 3.0.0
It turned out to be a known issue with manually saving a session in connect-redis. More info can be found at https://github.com/tj/connect-redis/issues/292.

RemoteCertificateNameMismatch when auth using SslStream on linux

I've come across some strange behaviour of dotnet SslStream, when running my dotnet-core app on linux environment.
here is the code:
TcpClient cl = new TcpClient();
cl.Connect("52.209.63.190", 443);
var ssl = new SslStream(cl.GetStream());
ssl.AuthenticateAsClient("api.bitfinex.com");
Auth result is success, when running on windows.
But same code ends with auth error (RemoteCertificateNameMismatch), when linux.
dotnet --info:
.NET Command Line Tools (2.1.4)
Product Information:
Version: 2.1.4
Commit SHA-1 hash: 5e8add2190
Runtime Environment:
OS Name: fedora
OS Version: 27
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/2.1.4/
Microsoft .NET Core Shared Framework Host
Version : 2.0.5
Build : 17373eb129b3b05aa18ece963f8795d65ef8ea54
Why code behaviour is so different on linux?
How can I handle it and pass ssl auth?
Thank you in advance
So, you can connect to that host with
TcpClient cl = new TcpClient();
cl.Connect("api.bitfinex.com", 443);
var ssl = new SslStream(cl.GetStream());
ssl.AuthenticateAsClient("api.bitfinex.com");
I don't know how you got the IP address of api.bitfinex.com, but it's under cloudflare, and may be you don't need to connect bitfinex with his real IP address.
But if it is required to connect that special IP address, you can override verification callback before you do any connection
System.Net.ServicePointManager.ServerCertificateValidationCallback =
(sender, certificate, chain, errors) => true;
Looks like the answer is simple: too old dotnet version.
2.0 seems to have some ssl issues, which were fixed since 2.1
When I installed the newest one (2.1.3), my app still didn't work, decause I had to uninstall prev version (2.0.5) manually to be able to use 2.1.3
Now the app ends with the same result on both windows and linux environments.
Many thanks to M. Hovhannisyan. I've started trying different linux versions, and figured out what I did wrong

Getting a WCF service (both host/client) to work on https on Linux with Mono

I have a small test console application that serves as the WCF host and another console application that serves as the client.
The client can reach the host via http, everything works fine so far.
But when switching to https, I get the following error:
Error: System.Net.WebException: Error: SendFailure (Error writing headers) --->
System.Net.WebException: Error writing headers --->
System.IO.IOException: The authentication or decryption has failed. --->
Mono.Security.Protocol.Tls.TlsException: The authentication or decryption has failed.
...
The steps so far I have attempted to solve the issue:
I have verified that the ca-certificates-mono package is installed
I have imported the CA certs to the machine store with (why do I need this if I work with a selfsigned cert?)
sudo mozroots --import --machine --sync
I created a selfsigned cert for testing with (as described in the Mono Security FAQ)
makecert -r -eku 1.3.6.1.5.5.7.3.1 -n "CN=Cert4SSL" -sv cert.pvk cert.cer
I added it to the mono cert store
sudo certmgr -add -c -m Trust cert.cer
I have also did tests with other stores (Root, My) and also using not the maching but the user's store - none did work, the same error on each attempt
I assigned port my service uses to the cert
httpcfg -add -port 6067 -cert cert.cer -pvk cert.pvk
I added ignoring the certificate validation
ServicePointManager.ServerCertificateValidationCallback += (o, certificate, chain, errors) => true;
This did not help either (but it got called, the cert object looked allright in the debugger).
The client uses this code to call the WebService:
IService svcClient2 = null;
string address2 = "https://localhost:6067/TestService";
BasicHttpBinding httpBinding2 = new BasicHttpBinding();
httpBinding2.TransferMode = TransferMode.Buffered;
httpBinding2.Security.Mode = BasicHttpSecurityMode.Transport;
httpBinding2.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
httpBinding2.MessageEncoding = WSMessageEncoding.Text;
httpBinding2.UseDefaultWebProxy = true;
ChannelFactory<IService> channelFac2 = new ChannelFactory<IService>( httpBinding2, new EndpointAddress( address2 ) );
svcClient2 = channelFac2.CreateChannel();
string res2 = svcClient2.TestHello( "Bob" ); // <----- this is where I get the exception
Any help is appreciated, I feel like running in circles.
A few infos about the environment:
I am using Ubuntu 14.04 LTS and Mono 4.0.2, IDE is MonoDevelop
edit: I have now built the very same projects with visual studio and C#, there it works as expected. The client can connect to the host on both http and https.
If i copy over the mono version to my Windows machine, I run into the same issue and error message as on Ubuntu.
Could this be a mono-related issue?

Resources