I have 2 different ubuntu VPS instances each with different ip addresses.
One is assigned as a chef-server and the other acts as a workstation.
When I use the command
knife configure -i
I do get options to locate admin.pem and chf-validator.pem files locally.
I am also able to create knife.rb file locally.
WHile setting up knife, I get a question which asks me to enter 'chef-server url' so I enter 'https://ip_address/ of the vps instance
But in the end I get an error message
ERROR: SSL Validation failure connecting to host: "ip_address of my server host"- hostname "ip_address of my host" does not match the server certificate
ERROR: Could not establish a secure connection to the server.
Use knife ssl check to troubleshoot your SSL configuration.
If your Chef Server uses a self-signed certificate, you can use
knife ssl fetch to make knife trust the server's certificates.
I used 'knife ssl fetch' to fetch the trusted_certs from the chef-server but still it doesnt work.
CHef experts please help.
Your chef-server has a hostname, the selfsigned certificate is done with this hostname.
The error you get is due to the fact you call an IP adress where the certificate is done for a hostname.
Two way: disable ssl validation (you'll have a warning but it will works) or make a configuration (using your hostname files for exemple) to use the chef-server hostname instead of ip address.
This is a SSL configuration point you may have with other servers too.
Related
i have installed a PLEX media server on my NAS an want to install my issued SSL certificate for my custom domain name (eg. customdomain.ddns.net).
I have setup PLEX media server running on port 32400 (default) and setup the port forwarding on my router for external access.
Then i followed the instructions on this page: https://blog.stefandroid.com/2021/08/27/plex-with-lets-encrypt-certificate.html but using an ordered certificated for 1 year.
The domain name is issued and setup correctly and i created a valid .p12 file from the certificate.
I entered all the information on the "Network" settings page in PLEX. But when i open up plex via my custom domain with port 32400 (https://customdomain.ddns.net:32400) i still get an certification error:
This server could not prove that it is customdomain.ddns.net.
Its security certificate is from *.17ed1f92d4c64c4cb135d9dd79589f7e.plex.direct.
Does anyone has a clue what am i doing wrong? And i don't want to use a reverse nginx proxy, cause that is not possible with my setup.
Thanks!
I am using a Docker container to run a bunch of services, all of those services make use of certificates to communicate to each other.
When starting up those services there is one in concrete that complains with the following error
> discovery_1 | INFO ttn: Got public keys for token validation
> discovery_1 | DEBUG Connected to gRPC server Address=localhost:1900
> discovery_1 | FATAL Could not start client for gRPC proxy error=x509: certificate is valid for discovery, not localhost
> ttnbackbone_discovery_1 exited with code 1
I have created the certificate for "discovery" user but still Docker runs it for the localhost, in some way, which I don't understand... I have also followed this tutorial of certificates usage from Docker but still I have the same error.
What can I do further?
THanks in advance,
REgards!
I encountered this today. x509 certificates have a Common Name attribute that some software use to match the DNS hostname of a server. Here was my error with a certificate with CN of localhost and a DNS hostname of docker1-staging:
error during connect: Get https://docker1-staging:2376/v1.26/containers/json: x509: certificate is valid for localhost, not docker1-staging
I'll have to regenerate the certificate used by the Docker server and make sure it has a CN value of docker1-staging. You'll have to do the same with a CN value of localhost.
Hello i have istalled to openfire into my computer.I am trying to login to spark using username password and ip address as domain but i am getting I am getting certificate hostname verification failed errror.I found that that they are asking to change server i tried that option as well no result.
When we install Openfire server, it generates self-signed certificates for SSL connections. Now if you are in development phase, you don't need to worry about this error. However, once you go into production, you might consider placing proper HTTPS certificates against your domain.
Certificate directory: OPENFIRE_HOME/resources/security/
I am trying to use knife from my laptop to connect to a newly configured Chef server hosted on AWS. I know what is listed below is the right direction for me but I'm not sure how to go about this exactly.
If you are not able to connect to the server using the hostname ip-xx-x-x-xx.ec2.internal
you will have to update the certificate on the server to use the correct hostname.
I had this same problem. The problem is that EC2 instances place their private ip into their hostname file. Which causes chef to self assign certs to the internal ip. When you do knife ssl check you'll probably get an error message that looks like this:
ERROR: The SSL cert is signed by a trusted authority but is not valid for the given hostname
ERROR: You are attempting to connect to: 'ec2-x-x-x-x.us-west-2.compute.amazonaws.com'
ERROR: The server's certificate belongs to 'ip-y-y-y-y.us-west-2.compute.internal'
connecting to the public IP is correct however you'll continue to get this error if you don't configure your chef server to use your public dns when signing the cert.
EDIT: Chef's documentation used to have steps to correct this issue, but since the time I initially answered this question they have removed those steps from their tutorial. The following steps worked for me with Chef 12, Ubuntu 16 on an ec2 instance.
ssh onto your chef server
open your hostname file with the following command sudo vim /etc/hostname
remove the line containing you internal ip and replace it with your public ip and save the file.
reboot the server with sudo reboot
run sudo chef-server-ctl reconfigure (this signs a new certificate, among other things)
Go back to your workstation and use knife ssl fetch followed by knife ssl check and you should be good to go.
What you could ALSO do, is just complete steps 1 - 4 before you even install chef onto the server.
Update public IP on Chef Server
run chef-server-ctl reconfigure on Server (No reboot needed)
Update the knife.rb on Workstation with new IP address
run 'knife ssl fetch' on the Chef Workstation
This should resolve the issue, to confirm run 'knife client list'
You can't connect to an internal IP (or DNS that points to an internal IP) from outside AWS. Those are nonroutable IP addresses.
Instead, connect to the public IP of the instance, if you have one.
We have IBM Sterling Connect Direct 4.2 on Windows 2003 Server, everything is working fine, even the SSL Configuration, we exchange files properly. Now, I have migrated all the configuration to a Windows Server 2008 cluster environment. Everything it's ok... I have configured the IBM Sterling Connect Direct 4.6.0.1 -even the SSL Configuration, we just have made a copy/paste of the certificates, keycerts and trusted files-. Everything it's ok and we are able to receive files under a SSL session. But... there is an exception.. The problem we are facing is when we try to send files to our partners we get this error:
Message ID: CSPA311E
SSL Certificate verification failed, reason= self certificate in certificate chain:
Followed by this error:
Message ID: CSPA309E
SSL3_GET_SERVER_CERTIFICATE certificate verify failed:
We are using exactly the same configuration, except by the IP and server name, that have changed. The certificates in any way are linked to the server name or the IP?
Any hint on this issue is very appreciated.
A certificate is issued for a specific domain name or IP address. I'm pretty sure that this is the reason for your error. You can check this with keytool.exe which is shipped with a JRE or JDK installation and is located in the /bin directory. So issue the following from your command line:
keytool.exe -printcert -file C:\path\to\your\file.crt
This will give an output like:
In the second line there you can see: Owner: CN=localhost, ... which means that this certificate is issued for localhost.
If this CN entry differs from new the IP address or domain name, you have two possibilities.
Crate a new certificate which is issued for that specific IP or domain. You can use the java keytool.exe again.
You need to update your client application which checks the validity of the certificate. Thereby you need to tell the client to don't check the certs CN name against the real IP address or damain name of the remote server. (Not recommended because of security reasons.)