Asymmetric private keys have two basic operations: they can Sign a message such that anybody with the corresponding public key can verify that the private-key-holder signed it and it hasn't been tampered with, and they can Decrypt a message that was encrypted using the public key. In addition to the direct usefulness of these operations, the private key can be used to prove ownership of a certificate; the certificate contains a public key, and the private key can (by using either signing or decrypting) prove to a third party that it is your certificate (assuming, of course, that the private key has not been leaked or cracked).
Is this private key used to confirm that the certificate you send over the internet really belongs to you?
That's definitely one of the things it's used for, yes. That step is important for Authenticating the server in a TLS connection - proving that it's actually the server you mean to talk to - and can also be used to prove a TLS client's identity when client certificates are used (sometimes called mutual TLS).
The private key is also a critical part of the Key Exchange part of a TLS handshake, when the client and server agree on a symmetric public key that they both know, but that an adversary snooping on the connection or even actively tampering with it (as a man-in-the-middle) will not know. For RSA key exchange (common for a long time but somewhat rarer now), the basic procedure is simple; the client generates a random secret, encrypts it with the public key (from the cert), and transmits it. Only the holder of the private key can decrypt it. A more complicated (but more secure) key exchange uses some form of ephemeral Diffie-Hellman key exchange; in this case, the server signs the DH parameters (using its private key), and the client only accepts those parameters if they can be verified using the public key from the certificate. In either case, if the attacker attempts to tamper with the key exchange, the exchange will fail (in one case, neither the attacker nor the server would have the symmetric key that the client is using; in the other case, the client would reject the server's parameters and refuse to derive the symmetric key at all).