I am setting up SSL for an IOT device that uses MQTT protocol acting as a client and connecting to a broker server. The server is using Certbot for SSL keys and registration. I configure the IOT device using AT commands and in the AT command I need the cacert, clientcert, and clientkey shown in the picture below. But I am wondering what are the names of these files on my server which is Ubuntu 20?
My best guess is one of the files below:
root#broker1:/etc/letsencrypt/keys# ls
0000_key-certbot.pem 0001_key-certbot.pem 0002_key-certbot.pem 0003_key-certbot.pem
or
root#broker1:/etc/letsencrypt/live/mydnsaddress# ls
README cert.pem chain.pem fullchain.pem privkey.pem
Unless you are using SSL Client authentication the only files you need on the client will be /etc/letsencrypt/live/<hostanme>/fullchain.pem
If you are using SSL Client authentication then you will need a certificate and private key specific to that client and that will not be issued by LetsEncrypt but by a private CA.
Related
Background:
I have a CA root certificate (.crt) file with me and when I try to use the same certificate in MQTT.fx desktop installation tool I am able to connect to the broker successfully.
Problem:
Whereas, when I try to use the same certificate and try to connect using Java with Micronaut framework I am asked for private key, password, etc.
What did I try:
I tried converting the .crt to pem and establish connection using micronaut by using these parameters certificate-authority, certificate, private-key (Passed the same value for all)
tried to create the client certificate using the CA certificate using openssl
Expected solution:
Establishing a Connecting with MQTT broker using java either with or without Micronaut framework.
Note: All I have is the .crt certificate provided by the client.
I have the root certificate pem file from a Linux server. The application that needs to connect to that server is telling me it needs a publicCert pem file and a privateKey pem file to communicate with the server.
Do I generate these from the root certificate? My thought is that I would feed openssl the path to the root cert and then it would dump out the publicCert/privateKey I want.
I've created the certs on the server as described here. Now I need to install on the downstream device as described here.
The input of client connection I need to use requires these parameters:
connString: 'HostName=foo'
protocol: MQTT
publicKeyCertificateString: certificateString or path to certificate
privateKeyString: keyString or path to key
new DeviceClient(connString, protocol, publicKeyCertificateString, privateKeyString);
Cert format: pem
Authentication Format: x509
You would only need the Root CA certificate to be available in the trust store of the downstream device. What you seem to be looking to do is mutual authentication. Azure IoT Edge doesn't currently support downstream devices to connect using client certificates (mutual authentication). (Edge device only supports symmetric key authentication but doesn't support x509 certificate authentication). For publishing messages using MQTT, you would need to generate a SAS token for the downstream device and then use it to communicate with iot hub (edge device would act as a transparent gateway).
Related : c# Azure IOT Edge Auto-provision with Device Provisioning Service(DPS) with x509 certificate sample needed
I have an unusual use case :
a web server on the Internet is serving pages through HTTPS,
inside those web pages, there are calls to XMLHttpRequests to a locally connected device (IP over USB)
the device supports both HTTP and HTTPS,
the device is accessible on http(s)://192.168.0.1
the http calls fail because of insecure content in a https page,
the https calls fail because the certificate is not trusted (self-signed),
Side question: Since the device is locally connected to the PC, the encryption is pretty useless: Does a http header exists that allows insecure connections to a specific URL ? (like CORS for cross domain)
Main question: Is it possible to obtain a certificate for a private IP address ?
Edit: it seems that Plex had a similar problem and solved it the way described on this blog. This is a way too big for me.
Is it possible to obtain a certificate for a private IP address ?
A certificate can be bound to an IP address (see this). You can issue a self-signed certificate to a private address, but a trusted CA will not issue a certificate to a private address because it can not verify its identity.
For example a certificate issued to 192.168.0.1 would be theoretically valid in any context, and this should not be allowed by a trusted CA
Plex solves the problem with a Dynamic DNS and a wildcard certificate. The connection are done using the name (not the IP) of the device which is resolved to the private IP
Does a http header exists that allows insecure connections to a specific URL ? (like CORS for cross domain)
No, it does not exist. The browser blocks your XHR connections because they are HTTP connections initiated from a HTTPS page (mixed-content warning). Non-secure content can theoretically be read or modified by attackers, even though the parent page is served over HTTPs, so is normal and recommended that the browser warns the user.
To fix the mixed-content and https errors, you could serve the content through HTTPS and a self-signed certificate, and request users to import your root CA at browser.
An SSL certificate cannot be issued for Reserved IP addresses (RFC 1918 and RFC 4193 range)/ private IP addresses (IPv4, IPv6), Intranet for Internal Server Name, local server name with a non-public domain name suffix.
You could however use a 'self-signed' certificate. Here's how to create one:
Creating a Self-signed Certificate for a private IP
(example https://192.168.0.1) :
You need OpenSSL installed.
For example, on Ubuntu, you could install it by: sudo apt-get install openssl
(It may already be installed. Type "openssl version" to find out)
For Windows, you could try this: https://slproweb.com/products/Win32OpenSSL.html
Once OpenSSL is installed, go to OpenSSL prompt by entering 'openssl' on the console (LINUX), or the cmd prompt (WINDOWS).
$ openssl
OpenSSL>
Now do the following steps to create: Private key, Certificate Request, Self-signing the certificate, and putting it all together, by using the below commands:
i) Create KEY called mydomain.key:
OpenSSL> genrsa -out mydomain.key 2048
ii) Use the key to create a Certificate request called mydomain.csr
You could accept the default options, or specify your own information:
OpenSSL> req -new -key mydomain.key -out mydomain.csr
iii) use the above to create a certificate:
OpenSSL> x509 -req -days 1825 -in mydomain.csr -signkey mydomain.key -out mydomain.crt
iv) Put all the above to create a PEM certificate:
exit OpenSSL (OpenSSL> q) and go to certificate location and do:
$ sudo cat mydomain.key mydomain.crt >> mylabs.com.pem
mylabs.com.pem is your self-signed certificate. You can use this in requests like https://192.168.0.1 if your server supports https. Remember to check the port number for https(443).
I read that ejabberd recommends to use STARTTLS negotiation for secure connection between communicating entities. When I install ejabberd, by default it comes with a TLS certificate.
Then, why do I need to buy a certificate to install? what is the purpose of buying a new certificate from Certificate Authoririty since we have a default certificate?
When I deploy ejabberd on the machine, how the default certificate will be used for my domain? How the default certificate will be verified by client?
You can use ejabberd with SSL / STARTTLS with the provided TLS certificate. However, that certificate is only a self-signed certificate. It means that:
You will still be able to encrypt the traffic between the client and the server.
You client will not be able to check that the server is the domain it pretends to be. To be able to know that the certificate can be trusted the client need to refer to a trust authority in some way.
In the second case, it means that if an intermediate network device (i.e Wifi access point) tries to impersonate your server, it can present any self-signed certificate to the user, pretending to be your domain.
So, you can definitely use self-signed certificate to encrypt traffic, but to protect your users against man-in-the-middle type of attacks, you need to find a way to let the client now it can trust the certificate.
This can be done either by buying a certificate from a trusted authority (that will certify your certificate domain) or by making the client support a list of well defined certificates. This is called certificates pinning, however it requires to build the list of acceptable certificates into your client, which may not be possible.
It may be fine in your case, so buying a certificate is not mandatory.
However, not use the default ejabberd self-signed certificate, even if you plan using a self-signed certificate. The certificate provided with ejabberd will not match your own domain. You should at least generate your own self signed certificate that match your actual XMPP domain: How to create a self-signed certificate with openssl?
The client will verify whether the certificate is issued for the domain name of the Jabber ID (JID), the part behind the '#'. (There are other options, but they are incompatible with the policies enforced by the browser vendors against CAs and therefore not practical.)
Unless you already have a business relationship to a certificate authority (CA), I would recommend anyone to use Let's Encrypt and stay away from self-signed certificates.
Some instructions to automate this and be nice to the Let's Encrypt servers can be found here and the linked wiki pages.
Summary (assuming you are running Ubuntu 16.04 LTS, want to run it on the domain example.org and only use the certificate for ejabberd):
Create /usr/local/sbin/auto-renew-letsencrypt with the following content:
#!/bin/bash
# Renew all Let's Encrypt certificates which are due for renewal
t=`mktemp`
# Try to be quiet unless an error is returned
letsencrypt renew > $t || cat $t
# Hooks are not yet supported by `letsencrypt` shipping with Ubuntu 16.04 LTE
# Crudely emulate --renew-hook; breaks if diagnostic messages change
if grep -q "The following certs have been renewed" $t; then
cat /etc/letsencrypt/live/example.org/{privkey,fullchain}.pem > /etc/ejabberd/ejabberd.pem
service ejabberd reload
fi
rm $t
Run the following commands to create and activate the certificate and the automatic renewal
apt install letsencrypt
letsencrypt certonly --standalone --domain example.org
cat /etc/letsencrypt/live/example.org/{privkey,fullchain}.pem > /etc/ejabberd/ejabberd.pem
chown ejabberd:ejabberd /etc/ejabberd/ejabberd.pem
chmod 640 /etc/ejabberd/ejabberd.pem
chmod 755 /usr/local/sbin/auto-renew-letsencrypt
echo $(($RANDOM % 60)) $((RANDOM % 6)) "* * * root /usr/local/sbin/auto-renew-letsencrypt" > /etc/cron.d/auto-renew-letsencrypt
am new to LDAP / Active Directory environment.
am trying to connect with LDAP / Active Directory using SSL support.
to connect LDAP/Active Directory, SSL certificate is required to establish the connection.
I have been googling, and most of the result is to "create certificate using Microsoft CA (certificate authority)". Is this is only way to generate certificate for LDAP/Active Directory?
How can i get SSL Certificate for LDAP / Active Directory?
Is there any other way to get the SSL Certificate for LDAP/Active Directory?
The OpenSSL tool can be used to:
generate a new self-signed certificate
generate a certificate request
retrieve an existing certificate from an LDAP server using LDAPS (but not StartTLS as of OpenSSL 0.9.8)
OpenSSL is available via the console on Mac OS and most Linux distributions.
You can get OpenSSL for Windows here:
OpenSSL Distributions
The Mac Keychain Access application can also be used to generate certificates.
LDAP client code that requires a secure connection should connect to the port upon which the directory server listens for SSL connections, or connect to the port upon which the directory server listens for unsecure connections and promote the connection security using the StartTLS extended operation. The certificate to which you refer is the certificate used by the directory server.