TLS es solo un canal protegido entre dos pares de comunicación, generalmente encima de TCP. No importa si un igual puede ser cliente y servidor o ambos al mismo tiempo (pero no con el mismo compañero). Y tampoco importa los roles en el protocolo de enlace TLS en qué dirección se estableció la conexión TCP.
Por ejemplo, en FTPS, la conexión TCP para la transferencia de datos se puede crear de cliente a servidor FTP (modo pasivo) o de servidor FTP a cliente (modo activo), mientras que el protocolo TCP sobre la conexión TCP siempre es iniciado por cliente para que el certificado del servidor se pueda usar para la autenticación para protegerse contra el hombre en el medio, es decir, a veces en la misma dirección de la conexión TCP (pasiva) y otras no (modo activo).
Otro ejemplo es SIPS (VoIP) donde un dispositivo SIP es cliente (para iniciar llamadas) y servidor (para recibir llamadas). En el caso de SIPS, la dirección de la conexión TCP y el protocolo de enlace TLS coinciden. La autenticación generalmente se realiza tanto para el cliente como para el servidor (es decir, mutuo) donde cada uno proporciona el certificado que coincide con el dispositivo. Y, si los roles cambian, se utilizarán los mismos certificados: si A llama a B, entonces el certificado de B se usa como certificado de servidor y A como certificado de cliente, si B llama a A, el certificado de A se usa como certificado de servidor y B como certificado de cliente. Y, en el caso de un proxy SIP, el mismo sistema puede ser tanto el cliente SIPS para algunos servidores como el servidor SIPS para algunos clientes al mismo tiempo.
Por lo tanto, no es un problema usar arquitecturas P2P como SIPS junto con TLS. Y también se pueden usar certificados en dicha configuración siempre que cada nodo tenga una dirección clara u otro identificador que pueda usarse como sujeto del certificado y luego verificarse durante la validación del certificado. De esta manera, se puede usar una PKI para un modelo de confianza más escalable en comparación con PSK o SRP.