Защита интерфейса администратора Wordpress на альтернативном порту

У меня есть собственный блог на Wordpress. По возможности я стараюсь защищать административные интерфейсы веб-приложений с помощью проверки подлинности сертификата клиента SSL и X.509. У меня все это работает должным образом с такими вещами, как phpMyAdmin, поэтому технические детали с веб-сервером все на месте.

Моя настройка хостинга:

• nginx 0.7.x
• PHP 5.2.10 с патчем fpm
• MySQL 5.x

Я запускаю все это на VPS, поэтому у меня только один внешний IP. У меня есть несколько других веб-сайтов SSL, работающих на коробке: один на порту по умолчанию, а все остальные на альтернативных портах (так что каждый может иметь другой сертификат, соответствующий их имени хоста).

Я намеревался создать два блока конфигурации сервера:

1. один обслуживающий порт 80 blog.domain.com, который возвращал 404, если вы пытались добраться до чего-либо в / wp-admin
2. другой, работающий на порту 8443 с SSL без ограничений URL, но требующий предоставления действительного сертификата клиента X.509.

Проблема, с которой я столкнулся, заключается в том, что Wordpress не любит, когда к нему обращаются через два разных порта. Всякий раз, когда я пытаюсь пойти в https://blog.domain.com:8443, он перенаправляет меня на https://blog.domain.com, который представляет собой совершенно другой виртуальный хост (основной сайт на сервере, работающий на порту по умолчанию). Затем я получаю сообщение об ошибке имени сертификата в браузере, и даже если я отменяю предупреждение, я больше не общаюсь с сайтом wordpress.

Основной URL-адрес блога хранится в таблице wp_options:

mysql> select option_value from wp_options where option_name = 'siteurl';
+------------------------------+
| option_value                 |
+------------------------------+
| http://blog.domain.com       |
+------------------------------+
1 row in set (0.00 sec)

mysql>

так что я не могу просто сделать вторую копию файлов блога с основным URL, установленным на https://blog.domain.com:8443 и получить доступ к интерфейсу администратора таким образом.

Любые идеи?

ОБНОВИТЬ

Поиграв какое-то время с предложенными ответами, я пришел к выводу, что невозможно делать именно то, что я хочу. Включение функций в wordpress приводит к тому, что пользователи делают запросы SSL к / wp- (admin | login | register), что они не могут сделать, если мне требуются сертификаты клиента X.509 на стороне SSL.

Лучшее решение, которое я придумал, - это настроить интерфейс SSL с аутентификацией по сертификату, который просто передавал запросы обратно на nginx без SSL. Даже в этом случае я не могу полностью отключить доступ без SSL к / wp-admin, потому что большая часть CSS и Javascript, используемых при регистрации пользователей и управлении профилями, происходит из этого каталога.

Я могу разрешить доступ к CSS, изображениям и Javascript в / wp-admin через HTTP и просто требовать SSL-доступ для скриптов PHP, но тогда пользователи не могут изменять свой профиль (цветовые схемы, отображаемые имена и т. Д.) Следующий шаг было бы идентифицировать подмножество PHP-скриптов, необходимых для обычных пользователей, и позволить им проходить через HTTP, отклоняя остальные, но тогда я подчиняюсь команде разработчиков WordPress, если они реорганизуют вещи.

Я предполагаю, что это сводится к тому, чтобы научиться управлять блогом только через SSL, хотя сервер позволяет мне делать это через простой HTTP.