Redirecting SSL request to non-ssl port

I agree with Dr. Klahn

If you're having a problem with your SSL Certificates it's not really going to matter which port you use, HTTPS will fail either way

If I may inquire, what exactly is the issue with your certificate?

Just generate a new SSL cert.

https://LetsEncrypt.org has provided free certs for years.

So i assume the only way for this is to open port 8080 in the firewall which would be a security problem.

We already have an SSL certificate running that expire this week. We have obtained new SSL certificates from godaddy and I have been trying to install it for last 10 days and it would not work. When I use openssl it says handshake failure. When i use browser to go to Apache tomcat homepage I get either page not found or TLS1.

openssl s_client -connect 10.60.61.xx:443

139744616851344:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1564435075
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)



When i try access from browser it says

This page cant be displayed
Turn on NLS 1.0, TLS 1.1 and TLS 1.2 in advanced settings and try connecting.
It this site persists it is possible that this site uses an unsopprted protocol or cipher suite such as RC4


All of these are turned on in browser. When I switch back to the old keystore and certificate it works fine .

We did migrate the windows 2008 Vm to a new server an i am guessing maybe keytool or IPV6 is causing something.

Let me know if you need any other info. I can post both keystores it it helps.

You can setup a quick and dirty reverse proxy that will handle ssl termination for you and forward the connevtions to your 8080 port.

software that come to mind include : stunnel, socat, haproxy, nginx... all will allow you to setup an ssl termination quickly

Once that works, change your redirect rule for port 443 to the ssl termination

This looks more like a configuration issue to me.

I'm not familiar with "Tomcat" so I had to do a little research..

When you updated your SSL Certificate, did you update your "keystore" ?

Yes, created a new keystore and new CSR and generated a new certificate files for Apache server.

I have a crystal reports server 2016 that uses tomcat 8 apache web server running on Windows 2008 server (VM).

The SSL certificate expires soon so we purchase a new one for the same domain.

I ran same steps to install the SSL certificate as 3 years ago on Tomcat 7 but Whenever I call the web server via browser I get a spinning wheel for a while and then this error.

We migrated our VM to a new hardware in January and old SSl certificate continued to work fine.

I also updated the tomcat "Server.xml" config file to reflect the new java keystore name and new keystore password and restarted the web server.

This page can’t be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://psscr.xyz.c


Here are the steps i used to create the keystore and import certificate to it.

1) Generate a Keystore

cd C:\Program Files\Java\jre7\bin

keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA  -sigalg SHA256withRSA -keypass secret19 -keystore tomcat10.keystore




2) Create a CSR

keytool -certreq -alias tomcat -keyalg RSA -sigalg SHA256withRSA -keystore tomcat10.keystore -file
file10.csr

3) Generate certificates on godaddy site for "Apache" server

4) Install root, intermediate and user certificate

keytool -importcert -alias root -file c:\cert_2019\Apache\GoDaddyRoot.cer -keystore tomcat10.keystore

keytool -importcert -alias intermediate -file c:\cert_2019_new\gd_bundle-g2-g1.crt -keystore tomcat10.keystore

keytool -trustcacerts -importcert -alias tomcat -file c:\cert_2019_new\7e73f2ce870361.crt -keystore tomcat10.keystore

When I check the old working certificate versus the new one I see a difference in Entrytype

The old working keystore shows entrytype = PrivateKeyEntry while
new one shows entrytype = "catrusted ca"

I am not sure why but it seems the new one is not linking all certificates into the private key.

C:\Program Files\Java\jre7\bin>keytool -list -keystore tomcat9.keystore
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 3 entries

root, Aug 2, 2016, trustedCertEntry,
Certificate fingerprint (SHA1): 47:BE:AB:C9:22:0E:78:78:34:62:A7:9F:45:C2:
54:FD:E6:8B
intermediate, Aug 2, 2016, trustedCertEntry,
Certificate fingerprint (SHA1): 27:AC:93:69:52:07:BB:26:27:CE:FA:CC:BE:4E:
F9:C3:19:B8
tomcat, Aug 2, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): BB:71:95:2E:83:6C:61:70:05:6F:EC:E9:DC:FD:
DD:6B:17:4B

C:\Program Files\Java\jre7\bin>keytool -list -keystore tomcat10.keystore
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 3 entries

root, Jul 22, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): 47:BE:AB:C9:22:EA:0E:78:78:34:62:A7:9F:45:C2:
54:FD:E6:8B
intermediate, Jul 22, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): 27:AC:93:69:FA:52:07:BB:26:27:CE:FA:CC:BE:4E:
F9:C3:19:B8
tomcat, Jul 22, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): B6:27:BE:DF:ED:EF:EF:4D:62:D2:F1:5C:CC:C1:A2:
AB:98:60:8E

I think the problem in new keystore is that the certificate chain in not getting imported into private key alias "tomcat".

This is why old one shows entrytype=privatekey while new one shows "trustedCertEntry"

I tried creating a PEM file for all of them and importing that into alias tomcat but it only imported the domain certificate.

If you do what you describe, setting up HTTPS proxy requests is complex.

You must proxy port 80 -> 8080 along with port 443 to port 8443, or something similar.

In other words...

HTTP != HTTPS

So you must have one path for HTTP proxy requests + another unique path for HTTPS proxy requests.

If you try to proxy port 80 or 8080 or whatever HTTP port to an HTTPS connection, you will have a hard failure with some sort of oddball message.

The write up in this question seems overly complex for an already running HTTPS system.

All that's required is this.

1) Generate a new cert, either using LetsEncrypt or some many CSR based process like GoDaddy.

2) Delete the old certs.

3) Point your config to new certs.

4) Restart your Webserver.

5) You're done.