I try to deploy bitwarden in my own server using ubuntu platform (self-hosted).
For that Bitwarden supports only HTTPS connection
While i configured Self signed ssl certificate using private IP address in Ubuntu by openssl
I faced an error about bad substituation
how to overcome the error?
Related
I have a problem configuring SSL certificates between my client and my Server.
My client, is a frontend application written in Angular, installed on a Web Hosting called V-Hosting which provides cPanel and through which it is possible to install a free Let's Encrypt SSL certificate (with auto renewal certificate).
Therefore, a user's connection to the website is protected by the certificate made available by CPanel - Let's Encrypt.
Instead the Server, a Backend application written in Java, is on a Contabo VPS (Virtual Private Server).
On this virtual server there is Windows OS and I have Jboss installed, where my .ear package is installed.
My problem is that I can't figure out how to configure an SSL certificate so that client and server can communicate over https, as now my domain https://example.com/ can't communicate with my server on JBoss http://IP_SERVER:8080/rest/api as the Server has no certificate.
So, client has a certificate (https) but server not (http) and they can't communicate each other without a certificate on Server.
How can I make the Client and Server communicate in HTTPS?
I tried to install Keystore Explorer on my VPS and generate a keystore to install on jboss but it's not the best solution because then I would have a Let's encrypt certificate on the client and one self signed by me on the server.
SYSTEM INFORMATION
OS type and version CentOS Linux 7.5.1804
Webmin version [1.998]
Virtualmin version [7.1]
I installed a wildcard ssl certificate from Letsencrypt but in the browser when verifying the certificate it shows CN = “domain.com” not “*.domain.com”.
What do I need to do, what settings to enter in order to display the correct wildcard certificate?
Thanks!
The server is not properly configured. TLS works with IPv4 for both 2much.info and bauhaus.2much.info. For IPv6 though there is no address with 2much.info but there is one for bauhaus.2much.info. Only, TLS is not enabled here, it returns instead plain HTTP on port 443.
IPv6 capable clients will usually prefer IPv6 to IPv4. The attempt of using Opera without VPN might be done in a IPv4 environment, so the working IPv4 address is used. When using the VPN though other systems will access the target and these might be IPv6 enabled - in which case the access fails.
This can also be seen in a IPv6 capable environment. It is working with IPv4:
$ openssl s_client -connect bauhaus.2much.info:443 -4
...
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
But failing with IPv6
$ openssl s_client -connect bauhaus.2much.info:443 -6
CONNECTED(00000003)
140692571469632:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:332:
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.
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).
Working with a standard MediaTemple server setup with an installed GeoTrust domain certificate I am getting different responses from openssl and web requests.
Visiting the site from a site checker site I get a good response and see my domain certificate and the full Geotrust certificate chain.
When using
openssl s_client -connect subdomain.domain.com:443 -showcerts -ssl3
from my local machine I see
Server certificate
subject=/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels
Panel/CN=Parallels Panel/emailAddress=info#parallels.com
issuer=/C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels
Panel/emailAddress=info#parallels.com
and Verify return code: 18 (self signed certificate)
openssl version -d = OPENSSLDIR: "/etc/pki/tls"
It's a Centos 6.x box.
The apache httpd.conf file points to a certificate and CA list in a completely different location: /usr/local/psa/var/certificates/ which would seem fine to me.
Where is the openssl s_client finding the Parallels certificate? It is not located in /etc/pki/tls. Is there a way to configure the box so that the openssl requests and apache use the same server certificate?
Thanks in advance!
openssl s_client gets the certificate from the server during the SSL handshake. OPENSSLDIR is only the place where any (optional) configurations for the openssl tool gets stored.
Note that you might get a different certificate with openssl than you have configured on your server because you need to use SNI (Server Name Indication) like the browser do. This feature is used if you have multiple certificates behind the same IP. To use this feature with openssl add the -servername hostname parameter and provide the name you expect. You must also remove the -ssl3 option since this restricts the connection to SSL 3.0 which is not only insecure but also does not support SNI.
Turns out that on MediaTemple servers they maintain certs in two locations. The apache server has a location for the CA file in its conf files that is different from where openssl maintains its CA files.
You can find the apache location in the conf files and the openssl location with
openssl version -d
Within MediaTemple's web administration pages you can use plesk to install the domain cert into the openssl location as the "server's" cert. The apache server should already have the cert and CA files in the right location. The MediaTemple custom apache configuration overrides the standard apache setup which sets apache's cert locations to be the same as openssl's.