I am trying to create the Azure VM and use the VM application to silently install the application. Link to the procedure is at https://learn.microsoft.com/en-us/azure/virtual-machines/vm-applications-how-to.
Application fails to install the driver with the error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
It looks like the driver can't be installed since some root CA is missing. And it can't be installed automatically since the user running silent install has no proper rights.
I tried to just create VM and then run silent install from the command prompt, and that works just fine.
Has anyone had problems like that and how was it solved?
I tried to reproduce same in my environment I got the error like below.
This error says root certificate, which is not trusted by the trust provider, as silently install is running sometimes root certificate is not installed automatically it may cause error on application installation.
To resolve this issue, try to download Microsoft Root Certificate
Click Start ->Run , type mmc , and then click OK
Click File -> Add/Remove snap in like below:
Click on certificate -> Add :
Select -> computer name and finish it.
In console1 MMC you can see certificate -> Expand Trusted Root Certification Authorities , like below:
Once the Trusted Root Certification Authorities as imported I can able to install the application successfully
At my workplace, we have a corporate proxy that signs every incoming connections and we need to authenticate to be able to connect to Internet. I've configured the proxy in way too many places, and I got most software to use it. Now, the only program left (for now) that disrespect my config is sdkmanager. So, how do I make sdkmanager respect my proxy/authentication/certificate config?
sdkmanager
Warning: File /home/users/n.gendron/.android/repositories.cfg could not be loaded.
Warning: java.net.ConnectException: Connection timed out (Connection timed out)
Warning: Failed to download any source lists!
[=======================================] 100% Computing updates...
Android Studio / Appearance & Behaviour / System Settings / HTTP Proxy is correctly configured, and Check connection says Connection successful.
Android Studio / Appearance & Behaviour / System Settings / Android SDK does fetch updates without errors. I can even install new Android SDK Platforms.
Android Studio / Tools / Server Certificates has the correct certificate imported
http_proxy, https_proxy and no_proxy are correctly configured in my .profile.
Certificate is added to multiple keystores with sudo /usr/lib/jvm/default-java/bin/keytool -importcert -file /etc/ssl/certs/guardianCA.pem -keystore /usr/lib/jvm/default-java/jre/lib/security/cacerts.
~/.android/androidtool.cfg has yet another copypasta of my settings
I guess it's too late for a reply, I was going through the same problem. So answering now so that others can get help from it.
Basically SDK manager proxy hasn't been set so using command line proxy tunneling is helpful in this case.
This post has been helpful for me installing android command line tools using sdkmanager on windows.
If all the path variables are set properly
"%ANDROID_HOME%\tools\bin\sdkmanager" "emulator" "platform-tools" "platforms;android-28" "build-tools;28.0.3" "extras;android;m2repository" "extras;google;m2repository" --no_https --proxy=http --proxy_host=10.60.11.11 --proxy_port=8080
or
you can navigate to the directory where sdkmanager.bat file is set it in the path variable, or run this command directly from that location
sdkmanager "emulator" "platform-tools" "platforms;android-28" "build-tools;28.0.3" "extras;android;m2repository" "extras;google;m2repository" --no_https --proxy=http --proxy_host=10.60.11.11 --proxy_port=8080
I am on linux Redhat OS. I was trying to import certificate using this command
keytool -importcert -alias 3dspace ...
as can be seen in the image below. But it doesn't allow to as it states that either the keystore was tampered or the password was incorrect.
To make matter worse, now I cant run the service httpd as well even though it was running prior to this problem. What can be the cause and how to solve them?
Thank you in advance.
I am getting an unable to get local issuer certificate error when performing an npm install:
typings ERR! message Unable to read typings for "es6-shim". You should check the
entry paths in "es6-shim.d.ts" are up to date
typings ERR! caused by Unable to connect to "https://raw.githubusercontent.com/D
efinitelyTyped/DefinitelyTyped/7de6c3dd94feaeb21f20054b9f30d5dabc5efabd/es6-shim
/es6-shim.d.ts"
typings ERR! caused by unable to get local issuer certificate
I have recently update to node 4 from a much earlier version and it sounds like node is much more strict when these kind of problems arise.
There is an issue discussed here which talks about using ca files, but it's a bit beyond my understanding and I'm unsure what to do about it.
I am behind a corporate firewall, but I can get to the url fine in a browser without any restriction.
Does anyone have any further insight into this issue and what possible solutions there are?
I'm wondering about reverting to node 0.12 in the meantime :(
Try
npm config set strict-ssl false
This is a alternative shared in this url https://github.com/nodejs/node/issues/3742
There is an issue discussed here which talks about using ca files, but it's a bit beyond my understanding and I'm unsure what to do about it.
This isn't too difficult once you know how! For Windows:
Using Chrome go to the root URL NPM is complaining about (so https://raw.githubusercontent.com in your case).
Open up dev tools and go to Security-> View Certificate. Check Certification path and make sure your at the top level certificate, if not open that one. Now go to "Details" and export the cert with "Copy to File...".
You need to convert this from DER to PEM. There are several ways to do this, but the easiest way I found was an online tool which should be easy to find with relevant keywords.
Now if you open the key with your favorite text editor you should see
-----BEGIN CERTIFICATE-----
yourkey
-----END CERTIFICATE-----
This is the format you need. You can do this for as many keys as you need, and combine them all into one file. I had to do github and the npm registry keys in my case.
Now just edit your .npmrc to point to the file containing your keys like so
cafile=C:\workspace\rootCerts.crt
I have personally found this to perform significantly better behind our corporate proxy as opposed to the strict-ssl option. YMMV.
This worked for me:
export NODE_TLS_REJECT_UNAUTHORIZED=0
Please refer to the NodeJS documentation for usage and warnings:
https://nodejs.org/api/cli.html#cli_node_tls_reject_unauthorized_value
Anyone gets this error when 'npm install' is trying to fetch a package from HTTPS server with a self-signed or invalid certificate.
Quick and insecure solution:
npm config set strict-ssl false
Why this solution is insecure?
The above command tells npm to connect and fetch module from server even server do not have valid certificate and server identity is not verified. So if there is a proxy server between npm client and actual server, it provided man in middle attack opportunity to an intruder.
Secure solution:
If any module in your package.json is hosted on a server with self-signed CA certificate then npm is unable to identify that server with an available system CA certificates.
So you need to provide CA certificate for server validation with the explicit configuration in .npmrc.
In .npmrc you need to provide cafile, please refer to more detail about cafile configuration.
cafile=./ca-certs.pem
In ca-certs file, you can add any number of CA certificates(public) that you required to identify servers. The certificate should be in “Base-64 encoded X.509 (.CER)(PEM)” format.
For example,
# cat ca-certs.pem
DigiCert Global Root CA
=======================
-----BEGIN CERTIFICATE-----
CAUw7C29C79Fv1C5qfPrmAE.....
-----END CERTIFICATE-----
VeriSign Class 3 Public Primary Certification Authority - G5
========================================
-----BEGIN CERTIFICATE-----
MIIE0zCCA7ugAwIBAgIQ......
-----END CERTIFICATE-----
Note: once you provide cafile configuration in .npmrc, npm try to identify all server using CA certificate(s) provided in cafile only, it won't check system CA certificate bundles then.
Here's a well-known public CA authority certificate bundle.
One other situation when you get this error:
If you have mentioned Git URL as a dependency in package.json and git is on invalid/self-signed certificate then also npm throws a similar error.
You can fix it with following configuration for git client
git config --global http.sslVerify false
Typings can be configured with the ~/.typingsrc config file. (~ means your home directory)
After finding this issue on github: https://github.com/typings/typings/issues/120, I was able to hack around this issue by creating ~/.typingsrc and setting this configuration:
{
"proxy": "http://<server>:<port>",
"rejectUnauthorized": false
}
It also seemed to work without the proxy setting, so maybe it was able to pick that up from the environment somewhere.
This is not a true solution, but was enough for typings to ignore the corporate firewall issues so that I could continue working. I'm sure there is a better solution out there.
If you're on a corporate computer, it likely has custom certificates (note the plural on that). It took a while to figure out, but I've been using this little script to grab everything and configure Node, NPM, Yarn, AWS, and Git (turns out the solution is similar for most tools). Stuff this in your ~/.bashrc or ~/.zshrc or similar location:
function setup-certs() {
# place to put the combined certs
local cert_path="$HOME/.certs/all.pem"
local cert_dir=$(dirname "${cert_path}")
[[ -d "${cert_dir}" ]] || mkdir -p "${cert_dir}"
# grab all the certs
security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain > "${cert_path}"
security find-certificate -a -p /Library/Keychains/System.keychain >> "${cert_path}"
# configure env vars for commonly used tools
export GIT_SSL_CAINFO="${cert_path}"
export AWS_CA_BUNDLE="${cert_path}"
export NODE_EXTRA_CA_CERTS="${cert_path}"
# add the certs for npm and yarn
# and since we have certs, strict-ssl can be true
npm config set -g cafile "${cert_path}"
npm config set -g strict-ssl true
yarn config set cafile "${cert_path}" -g
yarn config set strict-ssl true -g
}
setup-certs
You can then, at any time, run setup-certs in your terminal. Note that if you're using Nvm to manage Node versions, you'll need to run this for each version of Node. I've noticed that some corporate certificates get rotated every so often. Simply re-running setup-certs fixes all that.
You'll notice that most answers suggest setting strict-ssl to false. Please don't do that. Instead use the setup-certs solution to use the actual certificates.
My problem was that my company proxy was getting in the way. The solution here was to identify the Root CA / certificate chain of our proxy, (on mac) export it from the keychain in .pem format, then export a variable for node to use.
export NODE_EXTRA_CA_CERTS=/path/to/your/CA/cert.pem
There are different reason for this issue and workaround is different depends on situation. Listing here few workaround (note: it is insecure workaround so please check your organizational policies before trying).
Step 1: Test and ensure internet is working on machine with command prompt and same url is accessible directly which fails by NPM. There are many tools for this, like curl, wget etc. If you are using windows then try telnet or curl for windows.
Step 2: Set strict ssl to false by using below command
npm -g config set strict-ssl false
Step 3: Set reject unauthorized TLS to no by using below command:
export NODE_TLS_REJECT_UNAUTHORIZED=0
In case of windows (or can use screen to set environment variable):
set NODE_TLS_REJECT_UNAUTHORIZED=0
Step 4: Add unsafe param in installation command e.g.
npm i -g abc-package#1.0 --unsafe-perm true
In case you use yarn:
yarn config set strict-ssl false
Add:
process.env["NODE_TLS_REJECT_UNAUTHORIZED"] = 0;
Source: Ignore invalid self-signed ssl certificate in node.js with https.request?
I have encountered the same issue. This command didn't work for me either:
npm config set strict-ssl false
After digging deeper, I found out that this link was block by our IT admin.
http://registry.npmjs.org/npm
So if you are facing the same issue, make sure this link is accessible to your browser first.
For anyone coming to this from macOS:
Somehow, npm hasn't picked up correct certificates file location, and I needed to explicitly point to it:
$ echo "cafile=$(brew --prefix)/share/ca-certificates/cacert.pem" >> ~/.npmrc
$ cat ~/.npmrc # for ARM macOS
cafile=/opt/homebrew/share/ca-certificates/cacert.pem
Well this is not a right answer but can be consider as a quick workaround. Right answer is turn off Strict SSL.
I am having the same error
PhantomJS not found on PATH
Downloading https://github.com/Medium/phantomjs/releases/download/v2.1.1/phantomjs-2.1.1-windows.zip
Saving to C:\Users\Sam\AppData\Local\Temp\phantomjs\phantomjs-2.1.1-windows.zip
Receiving...
Error making request.
Error: unable to get local issuer certificate
at TLSSocket. (_tls_wrap.js:1105:38)
at emitNone (events.js:106:13)
at TLSSocket.emit (events.js:208:7)
at TLSSocket._finishInit (_tls_wrap.js:639:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:469:38)
So the after reading the error.
Just downloaded the file manually and placed it on the required path.
i.e
C:\Users\Sam\AppData\Local\Temp\phantomjs\
This solved my problem.
PhantomJS not found on PATH
Download already available at C:\Users\sam\AppData\Local\Temp\phantomjs\phantomjs-2.1.1-windows.zip
Verified checksum of previously downloaded file
Extracting zip contents
A disclaimer: This solution is less secure, bad practice, don't do this.
I had a duplicate error message--I'm behind a corporate VPN/firewall. I was able to resolve this issue by adding a .typingsrc file to my user directory (C:\Users\MyUserName\.typingsrc in windows). Of course, anytime you're circumventing SSL you should be yapping to your sys admins to fix the certificate issue.
Change the registry URL from https to http, and as seen in nfiles' answser above, set rejectUnauthorized to false.
.typingsrc (placed in project directory or in user root directory)
{
"rejectUnauthorized": false,
"registryURL": "http://api.typings.org/"
}
Optionally add your github token (I didn't find success until I had added this too.)
{
"rejectUnauthorized": false,
"registryURL": "http://api.typings.org/",
"githubToken": "YourGitHubToken"
}
See instructions for setting up your github token at https://github.com/blog/1509-personal-api-tokens
Once you have your certificate (cer or pem file), add it as a system variable like in the screenshot below.
This is the secure way of solving the problem, rather than disabling SSL. You have to tell npm or whatever node tool you're using to use these certificates when establing an SSL connection using the environment variable NODE_EXTRA_CA_CERTS.
This is common when you're behind a corporate firewall or proxy. You can find the correct certificate by just inspecting the security tab in Chrome when visiting a page while on your company's VPN or proxy and exporting the certificate through the "Manage Computer Certificates" window in Windows.
On FreeBSD, this error can be produced because the cafile path is set to a symlink instead of the absolute path.
I am running a server that accepts https requests. I have generated my own certificate. When going to the site in firefox I get the unknown certificate error, but that's fine. This (I think) indicates that port forwarding and such works.
I am trying to use svn with this. When using svn on the server (but using the external ip) it works. Again I get the certificate is unknown, but I don't care.
When using svn on mac OS X I get
SSL negotiation failed: SSL error code -1/1/336032856
I've found several posts on google about this, but they all say it's a bug with openssl version 0.9.8, and that using something higher should fix it.
I am currently using openssl 1.0.0c. I have no idea what's going wrong. I also checked the error log in httpd and nothing comes up.
Any ideas on this would really help.
Thanks
Upgrading from SVN 1.6.15 to 1.6.16 fix this issue for me.
I received the same error message when my Apache configuration was wrong - my ServerName parameter in httpd.conf did not match hostname in the self-signed certificate.
I started getting this error from older subversion clients (Tortoise 1.6.4 i think, and pysvn r1280) when our svn server had its Apache instance upgraded. It went from using OpenSSL 0.9.8n to 1.0.0d.
Tortoise got fixed by upgrading to 1.6.16 (uses OpenSSL 1.0.0d).
Fixing pysvn was a different story. The latest version (r1360) came bac kwith the same error. There didn't seem to be much info around apart from hints that OpenSLL might need upgrading. I tried copying in different versions of OpenSSL (libeay32.dll and ssleay32.dll) and here are the results:
0.9.8j (the existing DLL version, bundled with pysvn r1280) FAIL
0.9.8o (bundled with the latest pysvn, r1360) FAIL
0.9.8r (the latest in the 0.9.8 series) FAIL
1.0.0* (the 1.0 series is not binary compatible with pysvn) FAIL
0.9.8L (nabbed from CollabNet SVN 1.6.9 command line client) SUCCESS!
So whatever they fixed in release L got broken again soon after, or there's something special about CollabNet's OpenSSL binaries.
In my case it started happening after some certificates changes on the server side. I tried deleting the .subversion/ dir, updating openssl, openssh, svn, and nothing...
It got finally fixed when I replaced the url host name with the ip address of that host.
In existing working copies was enough with:
svn switch --relocate http://hostname.com https://ipaddress
Not sure if this is a bug or what, but it seems that the new certificates are not recognized and keeps using the old cached ones for a given host name.
I agree with the earlier answer by Lukas Cenovsky, that setting ServerName in the apache configuration fixes the problem.
In this link http://www.elegosoft.com/files/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf it is said that the error originates from the SSL library.
The full error message(just to enable better google indexing) I receive is:
$ svn ls https://www.OMITTED.dk/svn
svn: E175002: Unable to connect to a repository at URL 'https://www.OMITTED.dk/svn'
svn: E175002: OPTIONS of 'https://www.OMITTED.dk/svn': SSL handshake failed: SSL error code -1/1/336032856 (https://www.OMITTED.dk)
In the file /etc/apache2/sites-available/ssl (debian linux)
I added the ServerName as:
NameVirtualHost *:443
<VirtualHost *:443>
ServerAdmin webmaster#localhost
SSLEngine On
ServerName www.OMITTED.dk
See what happens if you eliminate the SSL problem by adding your generated certificate to your client's trusted certificate store.
One step ahead, my case is a MSWindows Client workstation and a CentOs server with Apache.
Using Tortoise Subversion 1.6.16, I realise that after execute a "svn checkout https://OMITTED.dk/project", I got the same ssl handshake error.
What I did was
update c:\windows\system32\drivers\etc\hosts with "IP_address
OMITTED.dk"
update the entries with the project directory. Edit the
file project/entries and replace the IP_address by OMITTED.dk.
Thus I try the command : svn update path_to_project --non-interactive --trust-server-cert.
Hope will be usefull