There are several possible caveats:
If sessions are stored server side, (i.e. PHP), both servers will need access to a shared session storage path. Otherwise, you'll lose sessions as the load balancer sends request from one server to the other, or possibly (gasp) have one user with two unique sessions. This can get particularly frustrating with AJAX. 'Sticky' sessions may also be possible, depending on your load balancer.
Both servers should share the same /tmp directory, if indeed you use any kind of temporary files while working to serve requests. This could be a temporary archive that is compressed for a download, a flat file DB that keeps track of something, whatever.
If you use SQLite3, you may notice some quirks that never surfaced before, especially if you are using something like NFS to share the database files between the servers. NFS is slow with this, so I recommend using something else. Distributed file systems like Lustre are easy to set up, or you could use GFS/OCFS2.
You probably want the load balancer to be what handles the SSL handshake, which then makes the request to the back end servers using any old self signed certificate.
Some general notes:
As noted, use a high performance file system for sharing directories. All shared files should live on network storage, not one of the web servers. Otherwise, if one goes down, both are useless, kind of defeats the purpose.
If the site uses a RDBMS, you have two options. Run it on both nodes and use a master-master sync, or put the DB server on its own home. I recommend the second because that gives your web servers a lot more elbow room to operate.
Load balancers need redundancy too.
In most cases, you can go from a single server to a load balanced farm with little to no changes to the actual site / application itself, but you will need to make sure that all nodes can read and write to the same files. This may require you to add some logic for locking in the app itself.