I believe the configuration file is jetty-selector.xml.
Shall look at it tomorrow.
Thanks for your help
1) The certificate which we have used is self-signed certificate.
2) jetty logs, jetty.xml and jetty-selector.xml are attached .
3) While configuring for HTTPS, we had mentioned the default port for HTTPS as 8443. We used the URL https://XYZ-prep:8443/api/jwt/login but clearly, it is not helping.
4) Then we changed to 8008 in the jetty-selector.xml and tried with https://XYZ-prep:8008/api/jwt/login - only to see the same results.
Should we have tried with http://XYZ-prep:8008/api/jwt/login ? Please notice that it is HTTPS in the former and HTTP in the latter.
5) We enabled jetty logs after following the instructions, but they are not capturing anything as well.
In my opinion, perhaps the issue lies with the self-signed certificate. I wonder if browsers these days support self signed certificates.
Apart from that, should we enable the REST API logs? I haven't used REST API logs before and am quite lacking of ideas as to how it would help.
Should we also check if ports 8443 and 8008 are being used by some other process?
Looking forward to your reply.
If you have followed the instructions, then your Jetty will be configured on port "8443" shown below:
Note: This can be any port that you want, but using 443/8443 is a standard for SSL.
If you performed the second part to the update of the Jetty configuration as in the instructions, then you will have both a HTTP (8008) and HTTPS (8443) port configured.
From what you have posted, you are using port 8008 for the SSL connection:
I suggest keeping the SSL and non SSL ports separate i.e. use 8008 for HTTP, and 8443 for HTTPS.
Thanks for your reply.
I need to bring to your attention that yesterday, we first tried on HTTPS keeping port 8443 in the web link as well as Jetty-selector.xml file.
After that, we reverted to HTTP and configured Jetty-selector.xml with port 8008. However, we forgot to remove HTTPS from web link.
I am now of the opinion that maybe those self signed certificates need to be added to browser as well.
Theres a section - "Importing a certificate into the Trusted Root Certification Authorities store". Maybe that will help.
Also wondering if ports 8008 and 8443 and being used by some other process.
I found this postman troubleshooting documentation.
Even after following the procedure, the web link in Chrome does not appear Secure.
Do you think this is a problem with the self signed SSL certificates?
are you able to access the link now that the SSL has been applied?
No. We are not able to.
I am wondering if something is wrong with the SSL certificates.
Because after importing the certificates in Chrome browser is not helping either.
To the left of URL, it should say "Secure" in shiny green with a lock beside secure.
That isn't happening still.
Do you think gathering REST API logs will help me here?
If you can not hit the Jetty server in the browser you have a bigger problem than the certificate.
1. jetty cant find the keystore
2. the port you selected is in use
3. keystore password is wrong
One thing that we have run into is trouble with the keystore path, for example having the keystore at "c:\keystore.jks" did not work.
You can try copying the keystore next to the "jetty-selector.xml" and changing the path from
<Set name="keyStore"><Property name="jetty.home" default="." />/etc/keystore.jks</Set>
Remember to do the same for <Set name="trustStore">D:/Certificate/keystore.jks</Set>
Then set the password of the keystore as "cleartext" and not using OBF, just for troubleshooting.
Check that your selected port 8443 is open in the firewall of the server.
If possible test from the server itself first using the browser navigating to:
You should get a response like:
HTTP ERROR 404
Problem accessing /. Reason:
Powered by Jetty://
If there is a problem with your certificate you should get a certificate error saying it's not trusted for example.
You do not need to import the certificates to the browser, it will just give a warning if it does not like the certificate if it does not match the URL you are attempting to connect to, or it does not like the ciphers and other things (dependent on the browser you are using).
The Jetty/Java combination is very specific to what is required for Jetty to start correctly when using certificates i.e. Jetty will not start if it cannot find all required certs and keys in the keystore(s).
As you are using a self signed certificate, and creating a custom Java keystore all the required keys and certs are contained in the one place so this "should" not be an issue.
The Jetty logs, if enough debugging is turned on, should be able to tell you what it does not like.
Thanks for your interest so far.
We escalated this case to BMC and even they have been helpless.
They are trying to blame it on Postman.
There's one thing that I would mention though.
There's one field in settings which says - SSL Verification - On/ Off.
Whenever its turned off, postman works just fine. However, when it's on, postman does not work.
So the question which popped into my mind is - is that field "SSL Verification - On/ Off" even relevant?
I looked up postman site and there's no adequate documentation. I am being pedantic about this particular field only because it sounds important. Is there any point in me pettifogging about it?