Assuming the applications aren't using certificate / public key pinning (or that you can alter the pins if they are), your best bet is almost certainly an intercepting proxy.
There are a number of intercepting proxies out there, but I'm most familiar with Portswigger's "Burp Suite" and the free version of it will work fine for this, so I'll generally assume you're using that (you could probably also make Fiddler or Zap work here). I'm going to write these instructions from the assumption that you've never used an intercepting proxy before, but note that there are tons of guides online to how to use these tools.
Install the proxy on a machine in the same network as your two applications (it can be on the same machine as the client - the one that sends the requests - but you will need to change the server app's listening port or the client's request port if you want to install it on a machine that ever acts as a server) and start it up. If you're using Burp, it's a Java app and will run on anything (Win/Mac/Linux/etc.) with a suitable Java installation. The proxy will generate a "fake" CA key pair for HTTPS; you'll need to export that public key and install it as a trusted root certificate authority on the client machine(s). Set the browser proxy settings to use the IP address and port where Burp is listening (let its listening port through the firewall if needed) and test whether you can browse HTTPS sites using the browser, and whether they show up in Burp's log. If so, you're good to go.
It's possible your .NET app will respect the system proxy setting, in which case you don't need to change anything else; when it tries to talk to the server it will route through the proxy, and you can see everything it sends and receives. However, most apps aren't proxy-aware. To handle that, you can set the proxy to run in "invisible" mode, where it just acts as a web server and forwards the request appropriately (you can also explicitly configure it to forward requests, as a "reverse proxy"). If your app listens on 443 or a similarly low-numbered port, you may need to run Burp as Admin/root. Once Burp is listening on the port that the client sends requests to, go to the HOSTS file on the client (\Windows\System32\drivers\etc\hosts on Windows) and edit it (will need Admin/root privileges). Add an entry for the hostname of the server, pointing to the IP address of the Burp proxy.
The client will now connect to Burp when it's trying to connect to the real server. Burp will accept the connection, negotiate TLS using its own certificates (this is why you had to install Burp's CA cert), log every request, and forward them on to the expected destination (the server) over its own HTTPS connection (which Burp opens as a client). Burp will also log the server responses, and forward them back to the client as its own responses.
If the server is identified only by IP address, you can either change the IP address in the client and configure Burp to forward requests to the real IP address (reverse proxy mode), or you can install Burp on the server and either make the server listen on a different port (which you'll set Burp to forward to), or change the client to send requests to Burp's port (which Burp will forward to the usual server port). In the very unlikely case that the server listen and client request ports are hard-coded and the server address is hard-coded and the server is identified by IP address rather than hostname... you'll need to use something like ARP spoofing to get the request routed to you, and set things up so your proxy intercepts traffic for which its IP wasn't the actual destination. This is totally possible - SSLStrip does it, for example, though not using Burp - but you'll need to look into how to set it up.
Now, with all that said, there are a few other options.
- Install on the client a modified version of the System.Net.Security assembly, such that all traffic through a TLS stream is logged to a file or similar. This might be complicated by assembly signing requirements, which would mean you'd need to modify the executable as well. This is all possible but could be a hassle. Also, if you don't have such a library to hand - one might exist out there but I don't know of it offhand - you'd need to decompile the official library and modify it, or install a shim library.
- Decompile the client and/or server assembly and just read what requests it makes/receives and/or responses it expects/returns. Unless obfuscated, decompiling .NET is quite easy - recent versions of Visual Studio include built-in support, or you can use a third-party program like JustDecompile or similar - and even obfuscated code can usually be figured out with some work (the public symbols can't be renamed or hidden, which helps).
- Decompile the client or server assembly and modify the function(s) that handle HTTPS requests/responses to additionally log the request/response text to a file or similar. Then recompile the assembly and run it instead of the original version (just move/rename the original, don't delete it).
(Obviously, if you would get in legal trouble for decompiling, don't do it)
