> node-nightly --inspect --debug-brk build/build.js
Downloading the nightly version, hang on...
FetchError: request to https://nodejs.org/download/nightly/index.json failed, reason: self signed certificate in certificate chain
at ClientRequest.<anonymous> (C:\Users\clu\AppData\Roaming\npm\node_modules\node-nightly\node_modules\node-fetch\index.js:133:11)
at ClientRequest.emit (events.js:310:20)
at TLSSocket.socketErrorListener (_http_client.js:426:9)
at TLSSocket.emit (events.js:310:20)
at emitErrorNT (internal/streams/destroy.js:92:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
at processTicksAndRejections (internal/process/task_queues.js:84:21) {
type: 'system',
errno: 'SELF_SIGNED_CERT_IN_CHAIN',
code: 'SELF_SIGNED_CERT_IN_CHAIN'
}
If you're behind the corporate proxy (which uses e.g.
Blue Coat
), you should use http instead of https for repository addresses, e.g.
npm config set registry="http://registry.npmjs.org/"
See:
Error: SSL Error: SELF_SIGNED_CERT_IN_CHAIN while using npm
.
You can also import failing self-certificate into your system and mark as trusted, or temporary disable SSL validation while installing packages (quick, but not recommended method):
npm config set strict-ssl false
See:
Error: SSL Error: SELF_SIGNED_CERT_IN_CHAIN while using npm
.
The recommended way (and more painful) is just to point to the right certificate file, e.g.
npm config set cafile "<path to your certificate file>"
See:
How to fix SSL certificate error when running Npm on Windows?
.
前面两个方法都是无效的,只能尝试导入证书
通过命令git config --list --show-origin找到git证书的位置
C:/Program Files/Git/etc/gitconfig http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
Using your favorite text editor you can open up your
ca-bundle.crt
file that you copied & your
.cer
files you exported from the browser. Copy the entire
.cer
text including the
----BEGIN CERTIFICATE---
and
----END CERTIFICATE---
to the bottom of your
ca-bundle.crt
file. Do this for all the
.cer
files you exported.
1.复制一份git的证书
2.然后把导出的node.js的证书,复制到git的证书下面(直接用notepad++操作)
3.配置npm证书
npm config set cafile 'C:\Users\clu\chuck-ca-bundle.crt'
还需要到处websense public primary certificate authority证书
To permanently accept a specific certificate
Try
http.sslCAPath
or
http.sslCAInfo
.
Adam Spiers's answer
gives some great examples. This is the most secure solution to the question.
To disable TLS/SSL verification for a single git command
try passing
-c
to
git
with the proper config variable, or use
Flow's answer
:
git -c http.sslVerify=false clone https://example.com/path/to/git
To disable SSL verification for a specific repository
If the repository is completely under your control, you can try:
git config --global http.sslVerify false
There are quite a few SSL configuration options in git
. From the man page of git config
:
http.sslVerify
Whether to verify the SSL certificate when fetching or pushing over HTTPS.
Can be overridden by the GIT_SSL_NO_VERIFY environment variable.
http.sslCAInfo
File containing the certificates to verify the peer with when fetching or pushing
over HTTPS. Can be overridden by the GIT_SSL_CAINFO environment variable.
http.sslCAPath
Path containing files with the CA certificates to verify the peer with when
fetching or pushing over HTTPS.
Can be overridden by the GIT_SSL_CAPATH environment variable.
A few other useful SSL configuration options:
http.sslCert
File containing the SSL certificate when fetching or pushing over HTTPS.
Can be overridden by the GIT_SSL_CERT environment variable.
http.sslKey
File containing the SSL private key when fetching or pushing over HTTPS.
Can be overridden by the GIT_SSL_KEY environment variable.
http.sslCertPasswordProtected
Enable git's password prompt for the SSL certificate. Otherwise OpenSSL will
prompt the user, possibly many times, if the certificate or private key is encrypted.
Can be overridden by the GIT_SSL_CERT_PASSWORD_PROTECTED environment variable.
I'm not a huge fan of the [EDIT: original versions of the] existing answers, because disabling security checks should be a last resort, not the first solution offered. Even though you cannot trust self-signed certificates on first receipt without some additional method of verification, using the certificate for subsequent git
operations at least makes life a lot harder for attacks which only occur after you have downloaded the certificate. In other words, if the certificate you downloaded is genuine, then you're good from that point onwards. In contrast, if you simply disable verification then you are wide open to any kind of man-in-the-middle attack at any point.
To give a specific example: the famous repo.or.cz
repository provides a self-signed certificate. I can download that file, place it somewhere like /etc/ssl/certs
, and then do:
# Initial clone
GIT_SSL_CAINFO=/etc/ssl/certs/rorcz_root_cert.pem \
git clone https://repo.or.cz/org-mode.git
# Ensure all future interactions with origin remote also work
cd org-mode
git config http.sslCAInfo /etc/ssl/certs/rorcz_root_cert.pem
Note that using local git config
here (i.e. without --global
) means that this self-signed certificate is only trusted for this particular repository, which is nice. It's also nicer than using GIT_SSL_CAPATH
since it eliminates the risk of git
doing the verification via a different Certificate Authority which could potentially be compromised.