Ask Questions and Find Answers

Yes, it is quite possible that you have to EXPLICITLY trust your own server.
Certificates are managed through keystores on Java level. Often there is just one, the default keystore installed/bundled with Java. It contains the standard certificates of various vendors. But if you need to trust other certificates you MUST trust those certificates (or there root certificates) yourself.
Only you can say, which certificates you trust. On servers I own, I often even remove the standard truststore. Simply because I trust nobody by default. I only add root certificates I need.

This one has been occurring for us for 4 years already. Every attempt at resolving through LESA hasn't worked. Could you expand on what this means "you'll need to manually configure it as trustworthy (that's on JVM level, nothing that Liferay could change)". Does that mean we have to certify our own server as trustworthy?

You seem to have solved this more or less with Christoph's help already, so I'll just add the canonical information here: In the case of https-RSS-feeds, the originating server offers an RSS feed through HTTPS. In order to build a secure connection, the client of this connection needs to trust that the server is indeed who they claim they are - otherwise encrypting a connection with an evil attacker won't add any security.
This trust is implemented through signed public keys: The server presents a public key that is signed by an entity that the client trusts for these purposes. If you connect your browser to a site that it doesn't trust, it will present a fat warning and you'll have to go through hoops to override this non-trust, if you want to see the page nevertheless. When Liferay is the client (as it is in the case of requesting an external RSS feed), there is just no way it could present any server operator with the question "is this certificate trustworthy". This means that Liferay must already trust the signing authority - if it doesn't, it won't create the connection.
In case of a proxy between an otherwise trustworthy server and the client (Liferay's RSS portlet), the proxy is prone to decrypt and re-encrypt with its own key. And typically Liferay won't trust that one. The truststore used by Liferay is typically the one used by the underlying JVM. That's the reason Liferay support can't help: This is a matter of configuring trust to arbitrary (custom) proxy certificates to sign all kinds of domains.
Unfortunately that's just how https works - everybody you trust can sign every domain there is.

This was simplified. I'm aware that the situation is more complex and contains some grey areas, not just black and white. But knowing that it's simplified should be sufficient for this short essay...

And you need the proxy in Liferay for other things? You can't turn it off for the Liferay server? Maybe you could start two Liferay instances, one with proxy and one without proxy? (I am just musing here)
I have two ideas:
1) Create a local proxy (it isn't that hard to do that e.g. with Apache) and "cheat" there. Forward all requests except those for localhost (and maybe some other internal servers) to the real proxy, send the rest directly to the server.
2) That rss feed you need. Create some instance (e.g. on some test system) that can be reached by the proxy and use it for development.

I might be able to write a client side RSS reader faster. Is there any appetite for Liferay to switch from server tech on this portlet?

Easiest will be to just publish it on Marketplace.
However, if you have any other requests that come out of your server (like REST-APIs accessing other systems) and they also need to go through a proxy, you'll still have to establish trust between your server and your proxy. Also, you might run into CORS issues, if the RSS feed doesn't declare to be ok with included from everywhere (we've tried this with the Radio Liferay audio player, which also consumes the RSS feed from client side - it required some extra header work on the server, which you can't assume every RSS host will do for you)