Global Internet Identity of people and organizations (and also identity of computers, servers and clients that are owned/run by said people and organizations) is verified by the means of digital certificates. Instead of having all internet users to establish individual trust relation to each other, all Internet users need to trust only to small number of well established internet notary public (aka, Certificate Authorities or CA). Certificate Authorities are big trustworthy commercial organizations that will verify identity of all internet users and issue them digital certificates that can be verified by anyone in the world.
Digital certificates are issued by commercial Certificate Authorities after extensive background checks that confirm identity of the people and entities and then if all the checks are successfully passed, CA would issue digital certificate to the person/organization that was checked to confirm person/entity name and/or computer/e-mail address that belongs to the person/entity. CAs charge money for this work.
There also could be Certificate Authority department in the company where employee is working, in this case certificate is issued to identify employee or employee's computer/server/client/e-mail-address for the corporate purposes.
Certificate Authorities are bundling private key. This signed bundle is called digital certificate and validity of digital signature can be verified by using public key of the Certificate Authority who signed the subject's certificate. As public key of Certificate Authority is well known to the whole world, the subject of the certificate (person or server) can present certificate to anybody to prove subject's identity. Subject of the certificate also retains it's secret private key (matching public key on the certificate) to prove it's sole ownership of the certificate.
The identity of the certificate owner can be checked in two steps: first by checking that presented public key on certificate is bundled with subject name by the digital signature of trusted certificate authority, then by checking that certificate owner also possesses private key that matches the public key on the signed certificate.
Certificate Authorities are usually big and reliable organizations and they are trusted by default by all internet users. To let people check their signature on subject's certificates, CAs have to make their public keys well known to the whole world. They distribute their public keys in the form of the digital certificates that bundle their name to their public key. They have to sign their own certificates themselves (self-signed or root CA certificates) and distribute them via reliable channels to all internet users. Reliable channels means, for example, that Microsoft Windows Operating system or Mozilla Firefox Web Browser all come with their own built-in list of root CA certificates that they trust unconditionally. Those Root CA certificates are used to verify digital signatures on the end user certificates (certificates presented by people, computers, web-servers, etc).
TLS Server needs server end certificate for its operation. This certificate is presented to the TLS client to confirm identity of the server. Also, if RSA-type certificate is used, its key is used to encrypt the TLS key exchange (the negotiation of the TLS session key that is used for bulk TLS encryption).
If you want TLS client to be able to authenticate TLS server, server should present valid certificate to the TLS client. Server certificate will attach server's identity to the server's public key by the means of CA's digital signature. TLS server certificate will have server address (IP or hostname or both), expiration date and public key of the server all sealed together by the means of the Certificate Authority's digital signature. Typically, TLS Client will check following:
To successfully check digital signature on the server certificate, client would need to have root CA certificate of the Certificate Authority that has signed server certificate. And for this signature to be trusted, Root CA certificate should be installed in the TLS client as "trusted". In most cases that would mean placing Root CA certificate into special list (or "store") which contains all Root CA certificates that are unconditionally trusted by the TLS client.
If server certificate is issued by some Commercial CA or by Corporate CA, then Root CA certificate that has signed the server certificate is most probably already installed as "trusted" on most client's computers on the internet or in the company.
But there could be some exceptions for smaller scale applications of the TLS server:
If any of those exceptions apply, server owner will have to become his/her own Certificate Authority (that is trusted by closed circle of users that are intended to connect to TLS Server). Proxy32 has built-in capability to make it possible. First, server owner can create his/her own root CA certificate and distribute it (without matching private key) via reliable channels to small group of people/computers running TLS clients that are intended to make connections to TLS server. People/computers running TLS clients should have this root CA certificate installed into store that is trusted by computer or by TLS Client application. After distributing his/her root CA certificate server owner can re-issue server certificate as often as needed, even if dynamic IP address of the TLS server is changing several times a day. As long as Root CA certificate is the same, all server certificates issued with it will be trusted by TLS clients that "trust" this Root CA Certificate.
There also can be rare cases when owner of the TLS server does not want to prove server identity to the connecting TLS client. This is not secure way of communication as the encrypted conversation between non-authenticated parties can be easily intercepted and highjacked by the MAN-IN-THE-MIDDLE. If such unsafe option is still needed, Proxy32 can create temporary self-signed certificate on the startup and use it for the TLS server. For this option to work, certificate checking should be disabled in the connecting TLS client.