Has anyone been successful with using Letsencrypt SSL with a default jetty install? I can't seem to get it right.
More info:
OS: Ubuntu 16.04
Jetty Path: /opt/jetty
Only thing adjusted is enabling http on port 80 in start.ini.
Problems I have run into:
When I input --module-ssl into the start ini, I get the error
No default protocol for ServerConnector#48aca48b{null,[]}{0.0.0.0:8443}`
starting jetty and it fails.
I have tried inputting the SSL info into the ini, as well as editing the .xml files with the info.
I know this is an older question, but in-case people stumble across it on Google with a similar issue:
The SSL module in Jetty is just the base cryptographic functionality. You need to do something with it - i.e. also enable the https or http2 modules.
In other words, for standard https you actually need:
java -jar start.jar --add-to-startd=ssl,https
So it's not the best of error messages, but:
No default protocol for ServerConnector
Means just that - it didn't previously have a protocol (implementation) to use the ssl module with, because the https (or http2) modules hadn't been loaded.
Related
Im trying to enable HTTPS using this guide (https://thingsboard.io/docs/user-guide/install/pe/add-haproxy-ubuntu/#step-10-refresh-haproxy-configuration) but i got stuck on step 9 i believe.
sudo certbot-certonly --domain your_domain --email your_email
I get the following error
certbot: error: unrecognized arguments: --tls-sni-01-port 8443
As far as i can tell, lets encrypt no longer supports this argument (tls-sni-01-port) or using ports other than 80 and 443. I got this from (https://serverfault.com/questions/805666/certbot-letsencrypt-on-different-port-than-443).
I am uncertain as how to solve this problem.
Here is my docker-compose.yml for Thingsboard + HTTPS through Nginx reverse proxy with automatic Let's Encrypt certificates: https://github.com/michalfapso/thingsboard_docker_https/
It uses linuxserver/swag which takes care of the certificates and is kept in sync with Let's Encrypt requirements by the linuxserver.io community.
I want to setup SSL certificate on tomcat, specification of my server:
OS: ubuntu 18.04 LTS
tomcat: 9.0.31
java: 1.8.0_242
I have these files:
xyz.key
xyz.ca-bundle
xyz.crt
I want to run tomcat on port 443 although I Know I can change port by using server.xml file.
By using the above files I can easily setup ssl in apache, But my question is which type of file format I should have in order to setup ssl in tomcat server and if I need some other format then how should I convert these files ?
Question is pretty unclear, but I assume what you're trying to do is run Tomcat standalone, not with Apache Httpd as a proxy. In that case, the easiest and best thing to do is to upgrade to a modern version of Java. Java 9 and later support PKCS12, which is easier than using JKS, so you should upgrade, either to 11 (the current LTS release) or 14 (current release).
Once that is done, you can use this tool to generate a CSR and save a key and help set up your configuration. It might be easier than doing this by editing files.
I'm having issues with TLS enabling in Mattemost. In my server I configured a lot of virtualHosts plus the mattermost files. In http everything was working fine.
Today I tried to setup TLS and https. I followed the instuctions as in https://docs.mattermost.com/install/config-tls-mattermost .html. Now I get this:
Please notice the error: I'm trying to access domain1.mywebsite.com and the error is "its security certificate is signed by domain2.mywebsite.com". domain2.mywebsite.com is one of the websites configured as virtualhosts in apache.
I did not configure any virtualhost for Mattermost, since I don't thing any is needed (and it worked flawlessly without one, and without TLS). But how can I tell mattermost (or the browser?) that the server of domain2.mywebsite.com is the same of domain1.mywebsite.com?
I generated the certificates using letsencrypt with the standalone option (sudo certbot certonly --standalone -d domain1.mywebsite.com) and didn't move any file, just enabled "UseLetsEncrypt": true, in config.json file.
Do you happen to have any idea about how I could fix this?
Thank you
Marco
You'll need to configure TLS on Apache. You'll needs to use separate certificates for each virtual host.
Here is information that might help you: https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html
Don't configure TLS on Mattermost if TLS is being handled by the proxy.
I am on a very newby level when it comes to AWS and SSL.
I got an SSL from GoDaddy. After that I generated the .csr file on AWS and I got an elastic IP. I created a subdomain on godaddy sub.mydomain.com that points to that IP.
I installed the certs following the instructions a found online, but now I get an error. I've tried installing apache2 on the EC2 and rebooting the instance but no luck yet.
Is there a way to remove the SSL cert or Fix the issue? When I got the SSL from GoDaddy, the zip had 2 files and ran the following command to install them:
sudo java -jar lib/ace.jar import_cert gd_bundle-g2-g1.crt gdroot-g2.crt sfroot-g2.crt 54581acbeba8a74e.crt
System said the certs were installed but now as I get that error, on the EC2 we have a unifi controller and we want to get that SSLrunning to accept payments for the hotspot.
I had the same issues my controller is hosted on an EC2 instance.
Check your system.properties which sits in /var/lib/unifi/ open the file with vim or your text editor of choice.
Have a look at your HTTPS options, the important ones are the ciphers and protocols.
The Protocols you need are TLSv1 and potentially SSLv2Hello there should be no other SSL protocols in there.
The Ciphers you ideally want are TLS, so for example TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA
If you are having issues throw them all in, CAUTION! only use this in a demo /test environment.
unifi.https.ciphers=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA
Remember once you have edited the system.properties you need to restart the controller.
sudo service unifi restart
Lots of help on the Unifi page
UniFi - SSL Certificate Error
UniFi - Explaining the config.properties File
UniFi - system.properties File Explanation
When running maven 3.0.5 our (newly swapped, apache proxy hosted) https certificate for Nexus is rejected with error:
hostname in certificate didn't match: <new.domain.com> != <*.old.domain.com> OR ..
This does not happen with earlier maven version (e.g. 3.0.3) and I noticed that the fix for 3.0.5 seem to match my problem: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0253
I've reviewed the certificate via Chrome etc and it seems fine. Running maven in debug (-X) doesn't give me much more information.
(I know it's boarder-lining to an Apache/Nexus question).
Also - this is a wildcard SSL certificate used by several other services, also proxied by the same Apache instance.
Any ideas?
Ok. Problem solved.
After reading up on Apache HTTPS and virtual hosts along with a crash course in HTTP proxies I got it.
Simply put: Apache cannot support multiple virtual hosts with different SSL certificates. This is because the Host-header used to proxy request is encrypted so we're in a hen-or-the-egg-situation.
We had Apache our configured like this as we wanted to re-directs from our old domain to the new one. In this situation Apache simply uses the certificate set up for the first virtual host: https://wiki.apache.org/httpd/NameBasedSSLVHosts
So why did Chrome get the correct certificate? Well - it appears that Chrome (and Apache) support an TLS extension which sends the host-name un-encrypted in the Client Hello (eg the 1st SSL message). Hence Apache knows which virtual host (eg Certificate) to send back.
Problem solved.
We will now set up our new domains virtual hosts 1st and our old re-directs last. This will enabled clients with the TLS extension to work 100% meanwhile it will enable the other clients to work for our new domain.