¿Cuál es la diferencia entre el archivo .cer y pfx? [cerrado]

La gente solía decir:

cer: certificado almacenado en el formato estándar X.509. Este certificado contiene información sobre el propietario del certificado ... junto con claves públicas y privadas.

pfx: significa formato de intercambio personal. Se utiliza para intercambiar objetos públicos y privados en un solo archivo. Se puede crear un archivo pfx a partir de un archivo .cer. También se puede utilizar para crear un certificado de editor de software.

** Obtuve una referencia de este enlace ¿Cuál es la diferencia entre un archivo cer, pvk y pfx? **

pero nadie dice cuándo debemos usar el archivo CERT y cuándo debemos usar el archivo PFX. Si es posible, analice la situación en la que deberíamos buscar el archivo CERT y cuándo deberíamos buscar el archivo PFX. Gracias.

Un .pfx incluye tanto la clave pública como la privada para el certificado asociado (NUNCA comparta esto fuera de su organización); se puede utilizar para TLS / SSL en un sitio web, para firmar digitalmente mensajes o tokens de autorización, o para autenticarse en un sistema asociado. Un archivo .cer solo tiene la clave pública (esto es lo que normalmente intercambia con los socios de integración); se puede utilizar para verificar tokens o solicitudes de autenticación de clientes, y es lo que recibe un cliente HTTP de un servidor en el protocolo de enlace SSL.

2 escenarios que funcionan de forma ligeramente diferente:

ESCENARIO 1:
Navegador web (cliente) accediendo a la página web (servidor) a través de HTTPS usando SSL.

El servidor tiene el archivo .PFX que contiene ambas claves. El cliente se conecta a un sitio web en el servidor y el servidor envía una copia de su clave pública (archivo .CER) al cliente como parte del protocolo de enlace SSL. A continuación, el cliente genera una "clave de sesión" y la cifra utilizando la clave pública recibida del servidor. La clave de sesión se envía de vuelta al servidor y se descifra para confirmar su autenticidad. Si tiene éxito, tanto el Cliente como el Servidor ahora comparten la "Clave de Sesión" para comunicarse usando cifrado simétrico (es decir, tanto el cliente como el servidor, ahora ambos cifran Y descifran todos los mensajes entre ellos usando la misma clave de sesión. Todo esto está siendo hecho detrás de escena en el fondo del navegador web, entre el momento en que ingresas la URL en la barra de direcciones y ves que aparece la página web.

ESCENARIO 2: La
aplicación (cliente) se conecta a un sitio FTP (servidor)
o
escritorio remoto (cliente a servidor) mediante SSH
(se aplicarán ambos ejemplos)

En este escenario, tanto el cliente como el servidor tendrán sus propios pares de claves públicas y privadas
(a diferencia de los otros ejemplos mencionados en este hilo, que solo explican cuando un servidor tiene ambas claves y el cliente solo tiene la clave pública)

Ahora, para fines de explicación, etiquetemos los pares de claves de la siguiente manera:
A1 y A2 = como las claves públicas y privadas del servidor respectivamente
B1 y B2 = como claves privadas y públicas de los clientes respectivamente

Usando este modelo, las publicaciones anteriores en este hilo hablaban de cuándo el servidor tiene A1 y A2 ( archivo .PFX ) y comparte solo una copia de A2 ( .CER ) con los clientes

Mientras que las conexiones FTP o SSH (existen otros ejemplos) consisten en claves A1 , A2 , B1 y B2 en toda la comunicación cliente-servidor. Por ejemplo, el
cliente se conecta al servidor FTP.
- El servidor envía copia de su clave pública (A2) al cliente.
- El cliente envía su propia clave pública (B2) de regreso al servidor, completando el protocolo de enlace.
- Esto ahora usará cifrado asimétrico

El servidor ahora tiene A1 , ( su propio privado ), A2 ( su propio público ) y una copia de B2 ( público del
cliente ) El cliente ahora tiene B1 , ( su propio privado ), B2 ( su propio público ) y una copia de A1 ( servidor Público )

Comunicaciones
cliente -servidor: el cliente usa A2 (clave pública del servidor) para cifrar los mensajes destinados al servidor, el servidor los descifra usando A1 (clave privada del servidor)

Comunicaciones de
servidor a cliente: el servidor utiliza B2 (clave pública del cliente) para cifrar el mensaje vinculado al cliente, el cliente los descifra utilizando B1 (clave privada del cliente)

Con respecto a los tipos de archivo .CER y .PFX, el servidor tendrá su propio .PFX que no debe distribuirse fuera de su organización, sino que debe distribuir el archivo .CER a los clientes.

se puede encontrar más información aquí:
https://www.digicert.com/ssl-cryptography.htm

y aquí:
/server/107433/why-does-a-ssh-public-key-sit-on-the-server-and-not-with-the-client

En mi experiencia (no es tan vasta como quisiera) utilizo un archivo pfx cuando configuro el enlace https en un servidor IIS (dado que contiene tanto la clave pública como la privada, está bien con ese archivo), un archivo cer es solo la parte pública del par de claves (la mayoría de las veces) y debe usarlo junto con un archivo .key al configurar el tráfico ssl en un servidor nginx o apache,

Hasta donde tengo entendido, no hay más razones difíciles para usar uno u otro,

Como se ha mencionado, la pregunta es un poco de manzanas y naranjas, ya que el archivo cer es solo la clave pública, pero el archivo pfx contiene claves públicas y privadas.

Entonces, una pregunta más justa sería cuándo querría usar un archivo pfx en lugar de un archivo pem. Dado que los archivos pfx han sido criticados por ser demasiado complejos, una respuesta justa a su segunda pregunta podría ser: solo querrá usar un archivo pfx si está ejecutando IIS y su configuración no le permitirá usar nada más. .

Fuente: https://en.wikipedia.org/wiki/PKCS_12 (La nota a pie de página a la que se hace referencia es un artículo de Peter Gutmann).

SSL utiliza cifrado asincrónico, lo que significa que una clave (la clave privada) se le da al servidor que "posee" el par de claves, mientras que la otra clave (la clave pública) se distribuye libremente.
Se denomina asíncrono porque los datos cifrados con la clave privada solo se pueden descifrar con la clave pública, mientras que los datos cifrados con la clave pública solo se pueden descifrar con la clave privada. Entonces, si desea enviar algo de forma segura al propietario, lo encripta con su clave privada y él será el único que podrá desencriptarlo. Si el propietario quiere demostrar que envió algo, lo encripta con la clave privada y cualquiera que tenga la clave pública puede desencriptarlo. (Una vez instalados los certificados, el navegador o la herramienta de correo electrónico lo hacen entre bastidores)
Dado que el propietario quiere mantener esa clave privada en privado, estará protegida con contraseña y SÓLO se le dará al servidor propietario (a menudo en un archivo PFX o P12). Pero la clave pública se distribuirá libremente (a menudo en un archivo CER).