Resolveu. Acontece que foi um problema de permissões:
Eu configurei uma configuração similar em uma máquina limpa do Debian Squeeze e funcionou desde o início. A diferença na saída de depuração foi:
[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 2, subject: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 1, subject: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 0, subject: /[email protected]/[email protected], issuer: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2
no lado "bom", vs:
[debug] ssl_engine_kernel.c(1321): [client 80.252.98.156] Certificate Verification: depth: 1, subject: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign PersonalSign 1 CA - G2, issuer: /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
[error] [client 80.252.98.156] Certificate Verification: Error (20): unable to get local issuer certificate
do lado "ruim".
A principal diferença entre as duas configurações são as permissões para o diretório / conf da instalação do apache em que residem os CA-certs. Por motivos de segurança, temos as permissões definidas para 750 e o dir de propriedade de root. Mover os arquivos CA para um dir legível (ou para ser preciso 'executável' para ser usado no caminho) fez com que o problema desaparecesse.
Portanto, parece que embora o mod_ssl afirme ler os certificados na inicialização do servidor, ele ainda precisa acessar os arquivos com hash durante a execução (e ter perdido seus privilégios de root).