A Web Server handles certificates and TLS connections
A web site itself is simply an HTML document, possibly including scripts and stylesheets, and references to other resources (external scripts, styles, images, etc.). The document itself is not aware if it is served via HTTP or HTTPS, and if so, which certificate was used for that.
Instead, these things are handled by the web server. A web server, such as nginx, can be given a certificate and the private key associated with the certificate. If configured to server HTTPS, then the web server will use said certificate in any incoming TLS connection.
Regarding Multiple Certificates
You seem to confuse "web site" for "web server", in regards to nginx. A web site is one document, where as a "web server" is one logical unit for nginx, with its own configuration and, more importantly, host name.
As such, nginx can be configured as follows:
server {
listen 443;
server_name server1.example.org
ssl_certificate cert1.pem;
ssl_certificate_key key1.pem;
}
server {
listen 443;
server_name server2.example.org
ssl_certificate cert2.pem;
ssl_certificate_key key2.pem;
}
...
If the web server was reached with the hostname server1.example.org, it would serve the certificate found in cert1.pem. Likewise, if it was reached as server2.example.org, it would server the certificate from cert2.pem.
Regarding Web Applications
Likewise, a "web application" is just a fancy name for a document with some server-side logic behind. But this also does not handle any certificates or TLS connections. In fact, it would make a web application a lot less portable if it did so, because any change in certificate would require changes to the codebase.
This split was done intentionally, as it separates two different tasks. The task of the web server is to accept incoming connections, parse HTTP requests, handle TLS connections, etc.. Once all of this is done, the web server forwards the parsed requests to the web application, which then handles all the application logic.
