Ese comportamiento no es parte de TLS v1.2
Pero no establece explícitamente por qué ha fallado el apretón de manos.
No puede. No está definido como parte del protocolo (TLS v1.2).
Cuando el servidor o cliente decide abortar una conexión, pueden elegir entre uno de varios mensajes alert .
Un mensaje Alert tiene este aspecto :
struct {
AlertLevel level;
AlertDescription description;
} Alert;
AlertLevel tiene un byte de ancho y solo tiene dos estados:
enum { warning(1), fatal(2), (255) } AlertLevel;
Y AlertDescription también tiene un byte de ancho. Pero de los 256 códigos de razón posibles, solo unos 30 son asignados y utilizados . Y de estos 30, simplemente no hay ninguno, que se ajuste al "Oye, te dije que quería un certificado de cliente, ¿por qué no me diste uno?!?" -bill.
(Y aunque parece que podría encajar, no_certificate_RESERVED(41) se usó para otra cosa. A saber, en SSLv3.0 se usó para la otra dirección: para que el CLIENTE le diga al servidor "Lo siento, puedo no le damos un certificado de cliente ". )
Ahora, para la pregunta más profunda "¿No tendría sentido definir un código de razón de este tipo si quedan muchos puntos de código no utilizados? En lugar de un error difícil, en gran medida inexplicable" , mi respuesta es simplemente: "No lo sé".
No veo cómo tener tal alerta podría debilitar el protocolo, pero el cifrado es complicado, y no estoy seguro.
Loadbalancer para dar un mensaje de error amigable
¿Pero qué pasa si quieres dar un mensaje de error amigable?
AFAIK, entonces usted debe hacer cosas un tanto complicadas con la lógica de equilibrio de carga y, inicialmente, permitir la conexión sin cliente, pero luego redirigir inmediatamente a una página de error. Apache puede hacer tal cosa con una regla similar a esta :
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !^SUCCESS$
RewriteRule .* /help/ssl-client-auth-required.html [L]
IIS define un mensaje de error HTTP llamado 403.7 Forbidden: Client Certificate Required . Creo que este es un movimiento inteligente (mejor que simplemente fallar, al menos), aunque el .7 de 403.7 no es estándar y creo que el mensaje de error pertenece a la capa TLS y no a la capa HTTP.