I'm using a docker gitlab/gitlab-ce:12.7.2-ce.0 image to run a GitLab. I'm trying to use a built-in container registry feature. Documentation sais: "If you are using the Omnibus GitLab built in Let’s Encrypt integration, as of GitLab 12.5, the Container Registry will be automatically enabled on port 5050 of the default domain.". Is it possible to configure GitLab builtin container registry with self-signed certs?
After a few tests, the configuration presented in the https://docs.gitlab.com/ee/administration/packages/container_registry.html turned out to be correct.
In addition, I placed the entire CA certificate path in /etc/gitlab/trusted-certs (in PEM format) so that when the GitLab container starts, the appropriate symlinks appear in the /opt/gitlab/embedded/ssl/certs directory.
I have the following issue when trying to use terraform.
I try to use terraform via an enterprise proxy.
So I set the HTTPS_PROXY env variable.
But the enterprise proxy act as a "man in the middle" (parsing web pages for viruses ...) and is configured with a security server certificate issued by our enterprise own authority.
It seems that terraform is not able to connect to (https) registries because this CA Root certificate is not trusted.
Is there a way I can configure terraform to use a custom CA Root trustore with (under Windows) ?
Bellow is the error I get Terraform try to connect (at init phase)
<!-- language: none -->
> terraform.exe init
Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
Error installing provider "aws": Get https://releases.hashicorp.com/terraform-provider-aws/: net/http: TLS handshake timeout.
Terraform analyses the configuration and state and automatically downloads
plugins for the providers used. However, when attempting to download this
plugin an unexpected error occured.
This may be caused if for some reason Terraform is unable to reach the
plugin repository. The repository may be unreachable if access is blocked
by a firewall.
If automatic installation is not possible or desirable in your environment,
you may alternatively manually install plugins by downloading a suitable
distribution package and placing the plugin's executable file in the
following directory:
terraform.d/plugins/windows_amd64
Finally the truststore was not in cause.
The issue was due to a setting the HTTPS_PROXY env to an httpS url rather than http.
Now it works fine with my custom root certificate in windows trust and even with NTLM authentication.
I am trying to deploy Kibana on Bluemix PaaS. Because Kibana is a Node.js application, it can be deployed as such on Bluemix. All i have to do:
Provide a simple manifest.yml file that details the app name and a couple of other things
Provide a Procfile that has just one line as web: bin/kibana --port=$PORT
Thus, I can run Kibana on Bluemix. Note that this is pushed via Cloud Foundry.
Also, I was able to install the marvel and sense plugins for Kibana.
Now, I installed the shield plugin. This plugin requires an ssl key and an ssl cert file to run. The path to these files must be provided in the kibana.yml file.
After installation, I tested the shield plugin natively and it worked just fine.
Here is the layout of the directory structure:
bin(d)
config(d)
installedPlugins(d)
node_modules(d)
sslFiles(d)
manifest.yml
Procfile
(d) represents directories. The sslFiles folder contains the ssl key and ssl cert files.
Before I could push to Bluemix, I knew that the paths to the SSL files would have to be relative to the app in Bluemix. Thus, in the kibana.yml file, I specified them as:
kibana.ssl.key:app/sslFiles/kibana.key
kibana.ssl.cert:app/sslFiles/kibana.cert
I did this as in Bluemix, I could see the following directory structure:
app(d)
bin(d)
config(d)
installedPlugins(d)
node_modules(d)
sslFiles(d)
manifest.yml
Procfile
Indentation represents containment. So, I pushed it to Bluemi using Cloud Foundry, but now I get a 502 Bad Gateway: Registered endpoint failed to handle the request error. I tried changing the paths to sslFiles/kibana.key but then I got a cannot find path sslFiles/kibana.key staging error.
What is responsible for my 502 error? Is it the path to the sslFiles? If so, how can I properly provide the paths?
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 added a self-signed certificate to my Teamcity BuildServer to introduce https support so that it can now be accessed at
https://ServerUrl:8443
(More details about how here )
The result was that I was able access the server via https, but my build agent was now disconnected. How to fix this?
The build agent works as a client to the build server and communicates with it using http/https, and it turns out that when you add a self-signed certificate the build agent does not accept it.
I needed to
Let the build agent know the new path for communicating with the server
Let the build agent know that it could trust the self-signed certificate
To change the path I did the following (see this post for more details )
Locate the file:
$TEAMCITY_HOME/buildAgent/conf/buildAgent.properties
Change the property
serverUrl=http:\://localhost\:8080 to your new url
To let the build agent know that it could trust the new certificate I had to import it into the build agent's key store.This was done using keytool:
keytool -importcert -file <cert file>
-keystore <agent installation path>/jre/lib/security/cacerts
( unless you've changed it, the keystore is protected by password: changeit)
The TeamCity team describes this process in slightly more details here
NOTE
If you need to retrieve your certificate from the TeamCity buildserver keystore, you can also use keytool to do this :
keytool -export -alias <alias name>
-file <certificate file name>
-keystore <Teamcity keystore path>
Here is a link to the TeamCity v8 documentation on the keytool.
I was doing this on a Windows Build Agent and had a self-signed SSL cert on my Amazon Linux Build Server. Here were the steps I took:
Went to build server in browser on Build Agent i.e. https://teamcity.example.com
Clicked on the certificate error in the URL and downloaded the cert to the local machine
Exported the certificate from the certificate explorer in windows into a cer file.
Used the keytool exactly as specified in the documentation
> keytool -importcert -file <cert file where it was exported to>
-keystore <path to JRE installation>/lib/security/cacerts
password: changeit
Restarted the build agent and viola!