ok - some basics ...
X509 defines a digital certificate format and its contents
a digital certificate holds identification about its owner, and also holds the PUBLIC key component of PKI keypair - the PRIVATE component is held by the owner, securely, on their machine
PKI encryption/decryption can only be done by the keyPAIR - what the private encrypts, the public can decrypt, and vice versa - if i encrypt something with your public key, only your private key can decrypt it - the added advantage is that if you encrypt something with YOUR private key, (stay with me!) only your PUBLIC key can decrypt it - hence i know it came from you, this is how digital signatures work
During the HTTPS handshake, the SERVER passes you (the client) its x509 - from that, you glean its public key, so you (the client) can now encrypt for the server's eyes only - believing that the server IS who it SAYS it is is a function of the x509 certificate chain (simply, the server cert has been countersigned by, say, Thawte, who have done that checking, and have their root cert on your machine)
At this point the server can insist it wants a KNOWN cert from you, but most don't (in most situations, you need to know it's the Bank you're talking to, they don't care who they're talking to) - typically your browser generates a one-time self-signed cert, you exchange that and now you can both talk to each other securely
the https API you use (for the client) will normally handle all the one-time-gen'd stuff, so you don't need to care about that
At the server end, you'll need to provide a certificate and private key - you can generate your own, if it's a 'toy' app, the certificate chain is not really useful - you may have to copy the x509 you generate into the CLIENTS certificate store, so that it trusts it
(Certificate chain 'trust' work by walking up the chain of certs until you find one you implicitly 'trust' because you happen to have a copy on your machine, normally installed/updated by the OS install)