How login to a Custom docker registry with SSL Cert from Windows server - windows

I am trying to login to a private repository from a windows machine using the docker command prompt, but I cannot figure out where I am supposed to place the SSL cert on a Windows machine.
I have successfully logged in from a Linux machine by placing the cert file in /etc/docker/certs.d/mydomain.com:port/
I have found in some of the documentation they are suggesting to place this .cert file in
C:\Program Files\Docker\certs.d{my domain goes here }{port}
But Still, I'm getting below error when I'm trying to log in
Error response from daemon: Get https://{my domain goes here }.com:{port No}/v2/: x509: certificate signed by unknown authority.
Can anyone help me to sort out this issue?

I think I have found my mistake, which is I have placed the .cert file in
C:\Program Files\Docker\certs.d{my domain goes here }{port}.
It should be in,
C:\ProgramData\docker\certs.d{my domain goes here }{port}
(Please note that this ProgramData folder is a hidden folder)

Related

Login to docker registry with client certificate under windows

The docker documentation here describes how to configure docker in order to connect to a registry that requires a client certificate. Under Ubuntu it works: I place the client.crt and client.key files into the folder /etc/docker/certs.d/<myregistry>/ as stated by the documentation ... and it works.
Unfortunately, there is no specific documentation how to configure docker under windows (wsl backend) to achieve the same result... and I stuck... I performed following attempts:
Imported the private key and certificate into the windows certificate manager, restarted docker
added the cert and key files into the docker-desktop wsl file system in /etc/docker/certs.d/<myregistry>/, restarted docker...
added the cert and key files into the docker-desktop-data wsl file system in /etc/docker/certs.d/<myregistry>/, restarted docker
added the cert and key files into the docker-desktop wsl file system in /root/.docker/certs.d/<myregistry>/, restarted docker
added the cert and key files into the docker-desktop-data wsl file system in /root/.docker/certs.d/<myregistry>/, restarted docker
I always get the same result:
PS C:\> docker login -u <remote_user> <myregistry>
Password:
Error response from daemon: login attempt to https://<myregistry>/v2/ failed with status: 400 Bad Request
Any Idea?
I found it! You need to place the cert and key files into the C:\Users\<user>\.docker\certs.d\<mysite>\ as follows:
C:\Users\<user>\.docker\certs.d\<mysite>\client.cert
C:\Users\<user>\.docker\certs.d\<mysite>\client.key
Docker must be restarted and after that, the login with the command docker login <mysite> does not fail anymore.

SELF_SIGNED_CERT_IN_CHAIN error while using Heroku Cli

I'm try to use Heroku CLI.
But when I want to do some commamd like:
heroku login, heroku log, etc.
The below error will show
SELF_SIGNED_CERT_IN_CHAIN self signed certificate in certificate chain
How can I sovled it?
I had the same issue however this helped me:
Verify your proxy export
export NO_PROXY='localhost,localnets, <company proxy IP settings>
Then verifying my companies .pem file stored in my user directory:
export NODE_EXTRA_CA_CERTS=~/.ssh/bc.pem
(or wherever you store it.)
Then try
heroku login
Its moreover related to security and firewall settings over machine and network.
If you are in secure network, try to connect over proxies / public network, then you can able to run heroku commands.
Or manually acquire SSL/TLS certificate on machine. Kindly refer to this link

Windows, cURL 60 unable to get local issuer certificate

I have already tried a lots of options available for this problem on stackoverflow, unfortunately nothing is working for me so far.
It started with composer installation. My env details are listed below:
OS: Windows 7
PHP V 7.1.10, XAMPP version
I am running MINGW64, (which was installed with git v2.1.5)
curl --version
curl 7.56.1 (x86_64-w64-mingw32) libcurl/7.56.1 OpenSSL/1.0.2l (WinSSL) zlib/1.2.11 libidn2/2.0.4 libssh2/1.8.0 nghttp2/1.26.0
Release-Date: 2017-10-23
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 HTTPS-proxy MultiSSL Metalink
Now here it seems CURL with OpenSSL is installed correctly.
When I was doing composer require or install it was reported me an error as follows:
I searched and figured out that its the local certificate problem so I downloaded the certificate/bundle from https://curl.haxx.se/docs/caextract.html, placed the certificate under C:\xampp\php\extras\ssl\ and changed the PHP.ini
curl.cainfo="C:\xampp\apache\bin\curl-ca-bundle.crt"
openssl.cafile="C:\xampp\php\extras\ssl\curl-ca-bundle.crt"
this never worked. Then I placed my certificates under C:\Windows\System32\curl-ca-bundle.crt, changed the ini still it didn't work.
Then I downloaded cacert.pem from
https://gist.github.com/VersatilityWerks/5719158/download
and repeated steps to make it work with pem file.
However I am afraid still no success here.
Can anyone help me whats wrong going on here? Any help in this direction is much
appreciated.
This is for Windows users, using curl-7.57.0-win64-mingw or similar version.
I have already shared this on another thread, but I think Windows users might stumble upon this question and my answer might help. So, sharing the step-by-step process.
This error basically means, curl is failing to verify the certificate of the target URI. If you trust the issuer of the certificate (CA), you can add that to the list of trusted certificates (e.g. It's a local IIS certificate, and you trust it for your development purposes).
For that, browse the URI (e.g. on Chrome) and follow the steps
Right click on the HTTPS secure padlock 🔒 icon on address bar
Click on certificate, it'll open a window with the certificate details
Go to 'Certification Path' tab
Click the ROOT certificate
Click View Certificate, it'll open another certificate window
Go to Details tab
Click Copy to File... button, it'll open the export wizard
Click Next
Select 'Base-64 encoded X.509 (.CER)'
Click Next
Give a friendly name that you can remember e.g. 'MyDomainX.cer' (browse to desired directory) and save
Click Next
Click Finish, it'll save the certificate file
So what did we do?
We basically saved the root certificate for the desired site (that we actually trust) as a local file. What do we do next?
Add that certificate to the list of trusted certificates
Now open this .cer file and copy the contents (including -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----)
Now go to the directory where curl.exe is saved e.g. C:\SomeFolder\curl-7.57.0-win64-mingw\bin
Open the curl-ca-bundle.crt file with a text editor (right click and open with...)
Append the copied certificate text to the end of the file. Save
What did we do now?
We added the certificate (content) to curl's main certificate bundle. So now curl will recognize this certificate and allow the domain.
Now your command should execute fine on curl.
Just posting this here for posterity as I spent the last 2 hours on this.
NOTE: only tested on windows.
Make sure you have the curl version with ssl included ( the latest exe installer has it)
Download the cacert.pem from http://curl.haxx.se/docs/caextract.html
Rename cacert.pem to curl-ca-bundle.crt
Move the cacert.pem file to the curl.exe directory.
Fixed.

Unable to load SiteMinder host configuration object or host configuration file

The application log in the event viewer shows
Unable to load SiteMinder host configuration object or host configuration file
for Siteminder 12.51 on IIS 7.5 (64bit) OS Windows 2008 (64bit).
When do you get the error? Is it when you're configuring the Webagent?
Anyway, verify the following.
Verify your environment variables are set correctly, if must have references to the Webagent files, you may need to export the envvars in the webagent or policy server folder (nete_wa_env...) file.
if the host config object you're using exists? Verify this using the
Admin UI
If the hostname is configured in the policy server as a trusted host
Verify if the settings are correct in the corresponding SmHost.conf file in the webagent folder
Verify and eliminate any duplicate or conflicting lines in your IIS config files which refer to siteminder.
Verify the host config object and the agent config object settings.
make sure WebAgent.conf is pointing to the correct SmHost.conf and SmHost.conf has the correct HostConfigObject defined (with the exact case that is used in the Policy Store).
If the HCO in the Policy Store is named "DefaultHostSettings" and SmHost.conf contains HostConfigObject=defaulthostsettings you will get this type of error.
Try re-registering the web agent with the policy server using the smreghost command.

Eclipse ADT known hosts

I have trouble getting the official Windows ADT 21.1.0 distribution to connect to a git repository. No matter what I tried(details below) it complains about host key not present in the registry and shows me no option to accept the host key. The remote server is running Gitlab and is under my control. There's no problem with connectivity or firewalls.
What I tried so far:
connecting without giving a password, with user git
connecting while giving a password, with another user
adding manually the host key in the known_hosts file that is found in the ssh home directory(Preferences->General->Network Connections->SSH2->SSH2 home).
The message is always:
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 xx:xx:xx...
Connection abandoned.
RSE works without any problems, only egit gives me problems.
You could workaround the problem by not using the ssh protocol with the git server, but instead the git or http protocol.
One reason for the above message can be using a folder called "ssh" instead of ".ssh" (note the dot). Some colleague of mine experienced that, and this can easily happen when using Windows explorer, as it will silently remove the dot, when creating a folder called ".ssh". You have to use the command line instead.

Resources