Necesita procesar certificados de 2 CA diferentes en 1 conexión

No estoy completamente seguro de si entendí bien tu pregunta, pero esto es lo que entendí:

• está en proceso de migrar de certificados emitidos por una CA raíz raízA a certificados emitidos por otra raíz CA raízB, es decir, tiene un certificado emitido por rootA y un certificado emitido por rootB.
• intenta hacer esto enviando todo lo que tiene (todos los certificados, todas las raíces) al cliente

Esto no funcionará por dos razones:

• Puede enviar solo un certificado de una sola hoja con cadena opcional (certificados intermedios) al cliente. Así es simplemente cómo funciona TLS.
• No debe enviar certificados raíz de todos modos al cliente. El cliente los ignorará de todos modos, ya que solo usa la CA raíz incluida en el almacén de confianza local de los clientes como anclajes de confianza.

Esto significa que, si desea migrar de usar certificados de rootA a usar certificados emitidos por rootB, simplemente necesita actualizar a todos los clientes primero para tener tanto rootA como rootB en su almacén de confianza, porque entonces aceptarán certA y certB . Una vez que todos los clientes estén actualizados, puede comenzar a utilizar certB. Después de eso, puede volver a actualizar los clientes para que solo tengan rootB en su almacén de confianza, de modo que ya no confíen en los certificados emitidos por rootA.

Esto supone que rootA y rootB son completamente independientes y no confían entre sí. Pero si controla ambos (por ejemplo, si desea reemplazar su propia rootA con 1024bit RSA con una nueva rootB con 4096bit RSA) o si hay alguna otra manera de hacer rootA trust rootB, entonces podría rootA crear una cadena de certificados intermediaB que tiene la misma clave pública que rootB. En este caso, habría dos cadenas posibles para verificar certB:

  1. certB - rootB
  2. certB - chainB - rootA

En este caso, podría utilizar certB inmediatamente sin actualizar todos los clientes que solo confían en rootA. Simplemente puede enviar tanto certB como chainB: los clientes que confían solo en rootA usarían trust chain 2 para la verificación y los clientes que ya confían en rootB ignorarán el certificado chainB enviado y utilizarán el certB de cadena de trust más corto.