Mike London

Ron McLeod wrote:There should be nothing confidential in the certs, but you do need to protect the private key.  If you don't use a keystore, how would you keep the private key safe?

That is a good point and supports using keystore approach I guess.

Thanks Ron.

-- mike

Stephan van Hulst wrote:I think what Mike means is, if he has a PEM-encoded certificate file, then why should he go through the trouble of converting it into a JKS/PKCS12 certificate file?

Honestly, it doesn't really matter what you use. If you already have a PEM-encoded certificate, good for you. Use it and be done with it.

Thank you! Yes, that's all I was asking.

-- mike

My question was whether using Coytoe is a better approach than the manual process of creating a keystore.

Maybe neither approach is better, just two ways of doing the same thing: Implementing the SSL certificate.

Sorry my question was unclear.

Thanks,

-mike

Is Coyote considered a more current way to secure Tomcat than all the (painful) steps to generate a keystore file?

I like that Coyote just refers to the cert files directly.

Thanks,

- mike

LOL...thanks Tim!

--mike

This is only a testing server so I'm not really worried about having Tomcat log in as administrator

Trying to setup a new user with just the right file permissions seems like it would take "a while" knowing Windows.... LOL

Thanks,

-- mike

Stephan van Hulst wrote:Using a non-admin account should be fine, recommended even.

You just need to set your file permissions that that account has access to them.

Thanks

Yep, logging the Tomcat account on as administrator fixed the issue. I had never needed to do that so it didn't occur to me.

Happy when things are so easy to fix!

Thanks.

--mike

Stephan van Hulst wrote:Uhh have you checked that the account that Tomcat is running under has file access to the files/folders that it needs?

Here's the thing, I've never needed to do any of that in the past.

Tomcat has Logon as: "Local Account". I'll change it to Administrator and see if that helps.

Will report back.

- mike

I have noticed that on Windows Server 2019 (did not happen on Windows Server 2016), my Tomcat web app cannot access certain folders (like /Users/Administator/ ...). Also, the web app cannot process "c:\program files\ ....".

If I move the directories directly underneath the root (C:\), the web app can access sub directories with no problems.

The same web app running on Windows 10 (or Mac) works fine regardless of where the directories are so something is happening on the server 2019 I don't understand.

The research I did thus far seems to indicate it "could be" Windows UAC.

It's odd that Windows Server 2016 did not have this issue so I'm not really sure what to do other than to fire up the registry editor and disable UAC.

Just wanted a double check here in case there's a better way to go about this.

Thanks,

-- mike

Tim Holloway wrote:

Tim Moores wrote:That's quite odd. In my experience, upgrading JavaMail from version to version has been seemless for a looong time, certainly since the 1.4 days.

Unfortunately, I know of no product and no vendor that has been completely immune to an occasional "dud" release. It's possible that none of the testers had a Big Sur machine to run under.

Well put.

-- mike

Tim Holloway wrote:Congratulations!

Was the working stand-alone app using the 1.6.2 version also?

I don't know if this means that the newer version was trying some sort of fancy tricks that annoyed the server or if there's an actual bug there - and since it's OS-specific, possibly even involving something within the network stack. Would be interesting to investigate if I wasn't busy on other stuff - and, of course, had a Big Sur system. But we'll take a win however we can get it.

Don't forget to put a comment about this in your POM against the day when things get upgraded!

Good question. No, in the standalone class, it's using 1.4.3. No wonder it worked.

I did add a comment in the POM so I won't reapply that 1.6.2 version at some point after I've (hopefully) forgotten about all this "fun".

Thanks Tim....you rock!

-- mike

Tim Holloway wrote:Well, again, it does sound like you might need the services of a network expert. About the only other theory I i can propose would be if the reply port was blocked.

Every tcp connection requires 2 network ports. One is the server port on the destination server. The other is the reply port on the source client. The reply port is typically a high-numbered port number assigned at random where responses from the server are returned. It is not a fixed port since a single client might have multiple server connections concurrently active. In fact, web browsers might be running 10 different requests in parallel for a single web page.

So the reply port needs to be visible through the local firewalls. In Linux using iptables, this is covered as part of a pair of stock rules for state=ESTABLISHED and state=RELATED. I don't know what the MacOS equivalents are, but it's possible that these rules aren't set up quite right on the offending machine. It doesn't make sense in that supposedly without that sort of access all connections on the client machine would potentially fail, but it's about my best guess.

Other than that, I suppose that somehow the mail client in the Spring Boot app is subtly different from the stand-alone and it's invoking something that makes the mailserver pause. I am, incidentally, assuming that your problems come when running the offending application directly on the client OS and not in a container, where networking gets an extra layer of complexity.

Also see if you can get the maillog from the mailserver for your connections. It may shed some light.

SOLVED! Well, sort of.

If I downgrade the JavaMail maven library from 1.6.2 to 1.4.4, it works.

I saw some offhanded remark in one of the hundreds of links I was reading and somebody just mentioned that.

Checking the various Maven repos, it's unclear to me what the actual current version is.

In any case, since 1.4.4 works, I'll change my maven imports to:

 <dependency>            <groupId>javax.mail</groupId>            <artifactId>javax.mail-api</artifactId>            <version>1.4.4</version>        </dependency>        <dependency>            <groupId>com.sun.mail</groupId>            <artifactId>javax.mail</artifactId>            <version>1.4.4</version>        </dependency> (from the 1.6.2 versions of each). -------

I can think of no good reason for this probable bug and certainly can't spend another several days trying to figure out how to report it, what's wrong with the library, etc.

I appreciate you both sticking with me on this!

Thanks Tim!

-- mike

Just to eliminate the CentOS mail server, I created a iCloud email account, but had the same timeout issues.

The thing that all the failures have in common:

1. Being on the Big Sur 2019 iMac,
2. SpringBoot (two versions tried: 2.4.2 and earlier 2.2.6.RELEASE).

The simpler sparkjava.com framework works fine on the 2019 iMac for sending email.
Sending email using the SpringBoot app works fine once I move it basically to any other computer.

That's all I know for now.

-- mike

Tim Moores wrote:That looks pretty normal - the client seems to connect successfully to the server, and transmit the message. Only when it tries to close the connection does the exception occur. Odd.

That last line is my own e.getMessage() " cause: " + e.getCause() line I'm writing to log4j.

Approaching debug-proof?

Do you still think that wireshark could be helpful?

It's odd that this only happens in the Springboot application but not in a separate war file using the "sparkjava.com" framwork.

Appreciate your replies.

-- mike