You're loosely describing the 2nd attack I mentioned but overlooking the issue of the SSL handshake. You cannot perform your attack without having the server's

You're loosely describing the 2nd attack I mentioned but overlooking the issue of the SSL handshake. You cannot perform your attack without having the server's private key, which as name suggests, is privately stored on the remote TLS endpoint. The private key is used to confirm that the client has received the websites certificates without getting MITMed. Since you don't have the websites private key you cannot use their public key in the way you described. The workaround for that is to create your own SSL certificate for that website (this will create you a public certificate and private key). Which means you will also need that new certificate CA signed otherwise the client (who's own SSL validations you cannot remotely disable like you implied) will give the user a warning about an untrusted certificate (the message will vary from client to client). This means you either need access to the targeted client to install your own CA certs, or you need access to a compromised signing authority.