У меня есть URL-адреса, которые мне нравится защищать с помощью сертификатов клиента ssl, используя такие директивы в моих конфигурациях apache:
SSLVerifyClient require
SSLVerifyDepth 10
SSLRequireSSL
SSLOptions +StrictRequire
SSLRequire %{REMOTE_ADDR} =~ m/^127\.0\.0\.1$/ \
or ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
and %{SSL_CLIENT_I_DN_CN} eq "xxx" \
and %{SSL_CLIENT_S_DN_Email} in {"xx@xx.com", "xx@xx.com",} )
Похоже, что в nginx нет никаких директив, чтобы справиться с этим, поэтому я предполагаю, что мне нужно передать все на бэкэнд Apache.
Это подводит меня к моему вопросу, как передать зашифрованный ssl? Все прокси-серверы расшифровывают ssl-пакеты на уровне nginx перед их передачей в Apache.
Если вы хотите, чтобы Apache обрабатывал проверку SSL, вам нужно поставить его перед nginx или сделать что-нибудь безумное с передачей клиентского DN в Apache через настраиваемый заголовок или что-то в этом роде - очень много работы.
Есть некоторые тем не менее, средства для проверки DN в nginx; в Документация по модулю HTTP SSL для nginx укажите возможные переменные (прямо внизу, и, к сожалению, разметка заполнена, поэтому для нее нет заголовка), но $ssl_client_s_dn должно быть тем, что вы ищете, и вы можете использовать директивы, подобные программированию nginx (if $ssl_client_s_dn ~= CN=something_or_other вроде того), чтобы перенаправить или вернуть 403, если вам не нравится представленный сертификат. Это будет сильно отличаться от того, к чему вы привыкли с Apache, но в конечном итоге способ Apache делать такие вещи тоже не является масляной живописью, поэтому все зависит от того, какой уродец вы предпочитаете ...
Однако мне любопытно, почему вы поставили nginx перед Apache ... любой из них должен быть способен выполнять всю работу по обслуживанию веб-страниц.