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?
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.
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.
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?
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.
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!
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.
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.