HTTP transmits its data in the clear. That's why SSL and HTTPS were invented by Netscape. Browser vendors adopted SSL (and its successor TLS) as the defacto standard for encrypting transmissions between the web server and web client.
Public keys, private keys, digital signatures, and digital certificates are all used within SSL, because SSL is actually an asymmetric encryption algorithm that uses private public keys to encrypt the data being transferred.
You generate a public and private key pair on your web server. You then combine the public key with information about yourself into a encryption certificate. You then send the certificate to a certificate signing authority, such as Thawte or Verisign. Once the signing authority verifies your identity or the identity of your business, the signing authority then applies its digital signature to your public key. You now have a signed certificate which you can configure your web server to use.
When you point your browser to an HTTPS site, the browser downloads the public key of the server and generates its own public key. It then encrypts its public key using the server's public key and transmits the encrypted key to the server. The server then decrypts the browser's public key using its own private key. The server and browser can then use each others' public keys to transfer information in encrypted form. (It's actually a little more complicated than than, but my description is correct in general.)
Web browsers have built into them the public keys of various signing authorities. Your browser can compare the key used to sign your SSL certificate to the signature it knows to be correct. If the signatures match, your browser assumes that since it trusts the signing authoritiy and the signing authority trusts you, it can also trust you. It accepts your server's public key for encryption. Your browser will also check to make sure that the HTTPS site name ("secure.foo.com"

matches the site name in the certificate.
The Apache web server uses external libraries, namely OpenSSL, to perform the cryptography to make HTTPS work. The OpenSSL libraries contain the functionality for you to sign your own certificates. Browsers will accept them and HTTPS will operate normally -- it's just that browsers will complain that it can't verify the signature on the certificate coming from the server.
Actually, though, I misspoke. The applicability of encryption algorithms other than SSL with HTTP really depend on how much effort you are willing to put out in getting the communications encrypted. You could write a web service that communicates to a custom web client application using encrypted channels.
If you want to know more, I recommend that you go to the source:
Applied Cryptography, by Bruce Schneier.
Want the best answers? Ask the best questions: TANSTAAFL!!