I installed a self-hosted Gitlab using the Helm chart on a Kubernetes cluster.
Everything is working fine except one thing: the cache.
In my .gitlab-ci.yml file I have
cache:
paths:
- .m2/repository/
- target/
But when running the job I have this warning when trying to download the cache:
WARNING: Retrying...
error=Get https://minio.mydomain.com/runner-cache/gitlab-runner/project/6/default?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=xxx: x509: certificate signed by unknown authority
And when uploading I have:
WARNING: Retrying... error=received: 501 Not Implemented
Uploading cache.zip to https://minio.mydomain.com/runner-cache/gitlab-runner/project/6/default
FATAL: received: 501 Not Implemented
But the certificate is provided by LetsEncrypt so it's not an unknown authority. When I go on minio.mydomain.com I can see that the connection is secure
I've also check that the runner is using the right credentials and yes it is.
I'm kind of lost here. Any hints is welcome.
Thanks.
You need to add the CA to the image that is hosting the cache.
You can follow these instructions from this gitlab issue for a workaround:
Update the helper image to have the ca chain for the self-signed certificate trusted.
FROM gitlab/gitlab-runner-helper:x86_64-latest
RUN apk add --no-cache ca-certificates
COPY ca.crt /usr/local/share/ca-certificates/ca.crt
RUN update-ca-certificates
RUN rm /usr/local/share/ca-certificates/ca.crt
docker build -t registry.gitlab.com/namespace/project/tools/gitlab-runner-helper:$SOME_TAG
Override the helper image used by GitLab by updating the config.toml to use the image you just build with the correct CA trusted.
If you are using the helm chart you can define KUBERNETES_HELPER_CPU_LIMIT environment variable and define it in envVars
Hope this helps.
Related
I'm running into certificate errors when I run "puppet agent -t" using a vault lookup module in my branch for the agent config. Here's the errors I get:
"Failed to apply catalog: certificate verify failed" and "The certificate for does not match its private key"
The error persists even after I swap back to the production branch for the agent, where we then have to do an SSL clean to get the prod agent config to apply successfully.
Would setting up puppet to be the intermediaery CA be a good idea? Anybody run into this before?
We also setup approle auth for vault, but to no avail. Any help would be appreciated, thanks!
Unsuccessful solutions: vault app role auth, generating new keys, defining the ssl_cert manually in the agent config, and cleaning the agent cert from the master.
We are using self-hosted runners (Windows) for GitHub actions. Recently, our company changed the proxy. We have updated the System Environment Variables to the new proxy, and we have updated the proxy details in .env file as suggested by GitHub documentation. And we have added the Root CA in the Windows Certificate Manager (Certificates - Local Computer -> Trusted Root Certification Authorities -> Certificates). But when uploading the artifact during workflow run, we got the below error message and workflow is failing.
Create Artifact Container - Attempt 1 of 5 failed with error: unable to get local issuer certificate
Error: Create Artifact Container failed: unable to get local issuer certificate
##[debug]Node Action run completed with exit code 1
How can we resolve this error? Is there anything that should be changed in runner configuration?
The problem is that the OpenID Connect URL I'm trying to reach uses self-signed certs. The plugin securityDashboards doesn't seem to like that:
Error: unable to verify the first certificate\ n at TLSSocket.onConnectSecure(_tls_wrap.js: 1088: 34)\ n at TLSSocket.emit(events.js: 198: 13)\ n at TLSSocket._finishInit(_tls_wrap.js: 666: 8)\ n code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE'
...
Client request error: unable to verify the first certificate
Since this seems to be a JavaScript error, my first approach was to point npm to the same keystore which also curl uses and which has no problem with the URL. Via npm config set cafile /etc/ssl/certs/ca-certificates.crt
After that didn't work I tried to disable the SSL verification altogether just to see if it works. Via npm config set strict-ssl false
That failed so I read the docs about certificate validation, tried to set up pemtrustedcas_filepath with the keystore above... didn't work.
Then tried to download the cert and use pemtrustedcas_content, but that didn't work either.
Out of options. Thanks for any suggestion!
Setting opensearch_security.openid.root_ca: /etc/ssl/certs/ca-certificates.crt in opensearch_dashboards.yml worked for me.
I have followed the getting started instructions here: https://linkerd.io/2/getting-started/ for installing linkerd but i am not able to install cli of linkerd.
Please see the command below: curl -sL https://run.linkerd.io/install | sh
Please see the error below:
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option
Can anyone please help me to solve it.
The provides installation instructions from the Linkerd website are indeed vague, they provide instruction for Linux (shell) users as well as a brew install command for OSX users.
If you are interested in installing LinkerD on your Windows machine, the recommandation is to download the binary (.exe - for Windows) directly form their release page: https://github.com/linkerd/linkerd2/releases
After you have downloaded the binary, you should be able to update your %PATH% environment variable to add the location of the binary, this will allow you to refer to the linkerd directly from your command prompt.
Linkerd started supporting Windows with a Chocolatey package: https://chocolatey.org/packages/Linkerd2
To use it, make sure that you have Chocolatey installed and run:
choco install linkerd2
After the installation, verify that the install was successful with:
linkerd --help
You should see the list of commands available to the Linkerd CLI.
pkg set-publisher: The origin URIs for 'solarisstudio' do not appear to point to a valid pkg repository.
Please verify the repository's location and the client's network configuration.
Additional details:
Unable to contact valid package repository: https://pkg.oracle.com/solarisstudio/release
Encountered the following error(s):
Transport errors encountered when trying to contact repository.
Reported the following errors:
Framework error: code: 60 reason: SSL certificate problem: unable to get local issuer certificate
URL: 'https://pkg.oracle.com/solarisstudio/release'
1.Make sure that ca-certificates service is running on solaris
svcs -xv
if not try starting using the below commands
svcadm disable svc:/system/ca-certificates:default
svcadm enable svc:/system/ca-certificates:default
Make sure that the below permission is set for all the certificates
If the above solution doesnot work
2. Take backup of all the certificates under /etc/certs/CA. Check for the corrupted certificates, by moving the certificates one by one to /etc/certs/CA in the location and starting ca-certificate service. The point when the service doesn't start is the certificate which is corrupted.
Make sure that the certificates in the location have below permissions
sudo chown root:sys /etc/certs/CA/*.pem