I'm using Axios to post to a remote API. Although it has worked great for several years, the requests have suddenly started throwing an error "certificate has expired' - despite the fact that the certificate has not expired. The API's domain has a working Let's Encrypt cert which isn't up for its next auto-renewal for another 2 months. In addition, if I run the exact same code on a different OS, it works (I'm on Linux; if I reboot the same dual-boot machine to Windows, the same node script successfully completes all of its Axios calls).
Why might Axios have suddenly started reporting an expired certificate, when the certificate is not expired?
(Note: I'm aware that I can force Axios not to check the cert at all, but that is not the desired solution - I'd like to understand why it's failing and rectify it).
The DST root formerly used and by default still bridged by LetsEncrypt just expired.
(note edits 10/05)
nodejs should successfully connect to a server using a LetsEncrypt cert with the 'compatibility' chain (i.e. still using the bridge to DST, even though it's expired, for old Android) IF
it has the ISRG root cert in its truststore aka root list. By default nodejs uses a compiled-in root list and v8.0.0 up contains the ISRG root. However application code like axios can replace or extend the compiled-in list, in which case it's the version/contents used by the application that matter.
AND nodejs uses OpenSSL 1.1.0 up (my previous belief that 1.1.1 was needed proved wrong on more thorough testing) OR the DST root is removed from the truststore (you can't remove it from the compiled-in list, but if you use a replacement list, you can omit/remove it from that).
On Linux, at least a Linux distro with a package manager, nodejs is probably built to use the system-supplied OpenSSL; check what the package manager shows for dependencies, or whether ldd $(which node) lists some version of libssl and libcrypto (noting that different systems/packagers sometimes use version numbers for these library files that are related to, but NOT the same as, the OpenSSL version they contain!).
On Windows, OpenSSL is usually not installed, and when it is, not necessarily in a fixed place, so nodejs is normally built to use its own (static-linked) OpenSSL. In this case the version of nodejs must be new enough, and I don't know what the mapping is, but it appears yours is sufficient.
Problem for me was I was using an old Node version by accident, switching to the latest released version fixed the issue.
Related
We are using Applet previously to get Key Store Certificates installed in client's machine. Now as chrome stops NPAPI, Applet is not working now, so finding some solution using Javascript / jQuery.
I am trying to get the total Certificate List for installs in KeyStore, but I can't find any solutions. Does any one know how to get the full Certificate List using JavaScript or jQuery?
You cannot do that with JavaScript running in the client.
See the following entry of the WebCrypto mailing list:
On Wed, Jun 24, 2015 at 1:50 PM, Jeffrey Walton
wrote:
I see the WebCrypto API will allow discovery of keys
(http://www.w3.org/TR/WebCryptoAPI/):
In addition to operations such as signature generation
and verification, hashing and verification, and encryption
and decryption, the API provides interfaces for key
generation, key derivation, key import and export, and
key discovery.
Certificates have public keys, and they are not as sensitive as private
keys.
Will the WebCrypto API allow discovery/enumeration of certificates?
Examples of what I would like to discover or enumerate (in addition to
the private keys):
Trusted roots
Client certs
Trusted Roots are in the platform's trust store. Client certs may be
in the trust store.
Thanks in advance,
Jeff
There are no plans from Chrome to implement such, on the hopefully obvious and significant privacy grounds.
Client certs contain PII. Trusted certs contain PII and
fingerprinting.
In modern, sandboxed operating systems, such as iOS and Android,
applications cannot enumerate either, as those platform providers
reached the same conclusion.
So no. Never.1
1 For some really long value of never
Get clone of below link https://github.com/scketches/ffPrintCert
install the jpm
npm install jpm --global
Create build for mozilla
jpm xpi
Upload extension in mozilla locally and check
Fire below url in mozilla
about:debugging
Load .xpi file from locally and check.
I am using Red Hat 8 (rhel8), my home router is Asus AC5300 running OpenVPN server. But my rhel8 VPN in Network Manager can't not connect to my OpenVPN Server.
Here is the error message I got:
[root#my-machine ~]# journalctl -f
nm-openvpn[30404]: TLS error: Unsupported protocol. This typically indicates that client and server have no common TLS version enabled. This can be caused by mismatched tls-version-min and tls-version-max options on client and server. If your OpenVPN client is between v2.3.6 and v2.3.2 try adding tls-version-min 1.0 to the client configuration to use TLS 1.0+ instead of TLS 1.0 only
[root#my-machine ~]# openvpn --version
OpenVPN 2.4.7 x86_64-redhat-linux-gnu
I've tried by adding tls-version-min 1.0 to my .ovpn file but still not working.
Note: In Linux Ubuntu it is working just fine, BUT not Red Hat 8
seems you have a problem with TLS ... take a look to this checks , maybe have to take a look SSL certificates:
Check for Certificate Name Mismatch
In this particular instance, the customer migrating to Kinsta had a certificate name mismatch which was throwing up the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error. As you can see from the SSL Labs test below, this is pretty quick and easy to diagnose. As SSL Labs states, a mismatch can be a number of things such as:
The site does not use SSL, but shares an IP address with some other site that does.
The site no longer exists, yet the domain still points to the old IP address, where some other site is now hosted.
The site uses a content delivery network (CDN) that doesn’t support SSL.
The domain name alias is for a website whose name is different, but the alias was not included in the certificate.
Certificate name mismatch
Another easy way to check the current domain name issue on the certificate is to open up Chrome DevTools on the site. Right-click anywhere on the website and click on “Inspect.” Then click on the security tab and click on “View certificate.” The issued domain will show in the certificate information. If this doesn’t match the current site you’re on, this is a problem.
Check issued domain on SSL certificate
Check issued domain on SSL certificate
Remember though, there are wildcard certificates and other variations, but for a typical site, it should match exactly. However, in our case, the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error actually prevented us from being able to check it in Chrome DevTools. That is where a tool like SSL Labs can come in handy.
Check for Old TLS version
Another possible reason is that the TLS version running on the web server is old. Ideally, it should be running at least TLS 1.2 (better yet, TLS 1.3). If you are a Kinsta customer you never have to worry about this as we always upgrade our servers to the latest and greatest supported versions. Kinsta supports TLS 1.3 on all of our servers and our Kinsta CDN. Cloudflare also enables TLS 1.3 by default.
(Suggested reading: if you’re using legacy TLS versions, you might want to fix ERR_SSL_OBSOLETE_VERSION Notifications in Chrome).
This is something the SSL Labs tool can also help with. Under configuration, it will show you the current version of TLS running on the server with that certificate. If it is old, reach out to your host and ask them to update their TLS version.
TLS 1.3 server support
TLS 1.3 server support
Check RC4 Cipher Suite
Another reason according to Google’s documentation for ERR_SSL_VERSION_OR_CIPHER_MISMATCH is that the RC4 cipher suite was removed in Chrome version 48. This is not very common, but it could happen in say larger enterprise deployments that require RC4. Why? Because everything usually takes longer to upgrade and update in bigger and more complex configurations.
Security researchers, Google, and Microsoft recommend that RC4 be disabled. So you should make sure the server configuration is enabled with a different cipher suite. You can view the current cipher suite in the SSL Labs tool (as seen below).
Cipher suite
Cipher suite
Try Clearing the SSL State On Your Computer
Another thing to try is clearing the SSL state in Chrome. Just like clearing your browser’s cache this can sometimes help if things get out of sync. To clear the SSL state in Chrome on Windows, follow these steps:
Click the Google Chrome – Settings icon (Settings) icon, and then click Settings.
Click Show advanced settings.
Under Network, click Change proxy settings. The Internet Properties dialog box appears.
Click the Content tab.
Click “Clear SSL state”, and then click OK.
Restart Chrome.
Clear SSL state in Chrome on Windows
Clear SSL state in Chrome on Windows
If you are on a Mac, see these instructions on how to delete an SSL certificate.
Use a New Operating System
Older operating systems fall out of date with newer technologies such as TLS 1.3 and the latest cipher suites as browsers stop supporting them. Specific components in the latest SSL certs will simply stop working. Google Chrome, in fact, pulled the plug on Windows XP back in 2015. We always recommend upgrading to newer operating systems if possible, such as Windows 10 or the latest version of Mac OS X.
Temporary Disable Antivirus
The last thing we recommend trying if you are still seeing the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error is to ensure you don’t have an antivirus program running. Or try temporarily disabling it. Some antivirus programs create a layer between your browser and the web with their own certificates. This can sometimes cause issues.
How can we programmatically make the autoUpdate of electron-builder trust a specific custom CA certificate when fetching updates using the GenericHTTPServer provider? The solution should not involve importing the certificate to the system and should be portable to all platforms: linux, macOS and windows.
I'm neither a node.js nor an electron expert. There seem to be a number of different API's around for accessing resources via HTTP, and I don't know which of those are used by the auto-updater. The following things I have tried:
electron.app.importCertifictate: Does not exist on macOS (and according to the docs, neither on windows). I haven't tried it on linux.
Handling the electron certificate-error: Does not seem to be triggered when auto-updater checks for updates.
Using the NODE_EXTRA_CA_CERTS environment variable did not have any effect. Also, this comment on a electron-builder GitHub issue suggests that electron-builder uses the electron http services, not those of node.
The documentation of the electron.net API claims that it tries to follow closely the Node API, but does not mention anything related to certificates.
All,
I have a C# ServiceStack console listener application running on Ubuntu using Mono. Within that application I have one service that must authenticate first at Appcelerator Cloud Services (ACS). I have tested the code locally(Xamarin .NET on OSX) and can see the code is fine. Based on the error and investigation using the almighty Google, Mono doesn't trust any secure sites by default.
So far I have tried using mozroots to import all mozilla root certs, and have used certmgr -ssl to import the certs directly from https://api.cloud.appcelerator.com. Nothing has worked so far.
I don't want to put code in place to bypass SSL in order to accomplish this as I think that is a cheap/insecure hack. There has to be a proper way to make this work.
Any and all suggestions appreciated!
Bruce
All,
I had it right. I was just missing the reboot which allowed Ubuntu to load up all the certs in the store.
Victory is mine, sayeth the coder...
I am supposed to fulfill a common-for-most-developers request to build/consume secure services using ssl/tls... via various communication protocols, not necessary wcf (web) services.
My problem is that I don't know much about certificates and I have been trying to get my background knowledge up to speed on the entire process.
The organization I am coordinating with issued 3 files for me to use:
AppName.cert.pem
AppName.csr
AppName.Key.pem
and also gave me a password for these.
The organization also gave me another certificate:
Organization.cert.pem
which is supposed to be used with their test tools.
The scenario is that the organization provided a test suite that runs on one vm, and the software I am building on another. I am supposed to import both of the certs into the vm with my software, and I think the organization's cert into the vm with the test software.
Problem is I don't know how, and the help links they provided are pointing to OpenSSL and some Java2SE tracing the secure requests/responses from either side....
Well, my code is written in C#, and both VM's use Windows Server 2008R2 x64 Standard/Enterprise. I am not sure how to import the certs, and configure them a) on a per application basis for a specific PORT and b) per domain basis?
Thanks,
Any help and guidance would be greatly appreciated!
Well, I downloaded the OpenSSL windows client and converted the AppName.cert.pem, AppName.csr AppName.Key.pem into a single consolidated AppName.PKCS12.
I later imported the result using the Cert Manager (MMC Snap In) in each WS2008R2 VM environment and it worked just fine.
It turns out that the Cert Manager also does understand what is a *.cert.pem file so I was able to import the Organization.cert.pem as well on both VM's.
Thanks
PS: Never read instructions about Windows config written by a Linux/Unix nut-job. This whole exercise of certificate management would've been easier if the person that wrote the test software manual (which I ported from Linux by the way...) didn't send me on a wild goose chase due to his lack of understanding of the capabilities of the Windows Server Environment... No need for OpenSSL.
<bleepzter/>