I created a VM in Azure with the name myedgeserver and installed the IoT Edge runtime on it. Afterwards I created a dns name for the server, resulting in the name myedgeserver.westeurope.cloudapp.azure.com.
When installing the server it creates a self-signed certificate with the name of the host, i.e. myedgeserver.
When connecting to the edge server with the fqdn (on port 8883 mqtt) it returns this certificate, which generates an error on the client since the client expects a certificate with the fqdn.
I changed the hostname in /etc/aziot/config.toml and ran
sudo iotedge config apply
but I'm still getting the certificate with only the vm name.
How can I regenerate this self-signed certificate on the edge server using the fqdn?
You will have to regenerate the certificates and use them instead for IoT Hib and your edge device (your VM). Follow the below link to generate the certificates as outlined in the article.
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/iot-edge/how-to-create-test-certificates.md
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!
Does anyone know how I can enable TLS Authentication on an application running inside an AWS Ubuntu machine.
To be specific, I have an Ubuntu machine on AWS running Linux Container (LXC) and LXD (a framework on top of LXC that provides REST APIs to access Linux Containers, among other things). I generated certificate and key on the Ubuntu host using LXC command line utility. I then tested whether the certificate works locally by running curl command providing the --cert and --key options to it, and everything works fine.
I then copied the Certificate over to my local machines (Mac OS X) keyChain and tried accessing the Ubuntu Server (which btw has an open security, allows traffic from everywhere on any port.) It gives me the error : "This server could not prove that it is X.X.X.X . Its security certificate is from ip-X.X.X.X".
I noticed that the certificate has the DNS name value as the private IP address given to the machine by AWS instead of public IP address.
Does any one know how I can access my TLS enabled application inside an AWS Ubuntu machine from outside, public network?
Please let me know if things are not clear and I would be happy to provide more details.
Within the certificate is a field that specifies what machine name or IP address the certificate should be coming from. This prevents another site from grabbing the same certificate and presenting it as the other site's certificate. The issue in this case is that your certificate specifies the AWS internal address, but the client sees the external address of the server.
The solution is simple: generate a security certificate with a subject alternative name (SAN) that is the external IP address rather than the internal IP address. External clients will then see the certificate IP address as matching the address they went to.
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.
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.)
We have an test environmnet where the physical AD server is set up for LDAPS connections and a Hyper V virtual machine running the webserver with our AD management web app loaded up. We have set up the x509 certs on both the physical AD server and on the virtual webserver. We are able to link to the AD server using SSl via Ldap.exe with no problems. When we try to access through the web browser it fails to connect. The event logs show an Schannel event with
"The certificate received from the remote server was issued by an
untrusted certificate authority. Because of this, none of the data
contained in the certificate can be validated. The SSL connection
request has failed. The attached data contains the server
certificate."
If we try the same thing from two phyisical boxes it works fine and likewise if we try to access the AD server from a virtual machine without using LDAPS it works fine.
I have gone on to the server and via the certificate snap in deleted the hyper v virtual machine management's self signed trusted root cert and restarted the service with no change. I can't find anything else relevent to our setup to try.
Anyone have any insight in to what we are missing on the virtual machine that is causing this failure?
According to me the message :
"The certificate received from the remote server was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The SSL connection request has failed. The attached data contains the server certificate."
Indicates that you do not intstall the public key certificate of the certificate authority on your client (Virtual Web server) certificate repository.
Try to install it on computer repository, but also on the reposository of the user which is in charge to start IIS.