Назад | Перейти на главную страницу

Требования для перенаправления между двумя доменами с https с разными владельцами

Недавно я начал работать системным инженером. Однако мне все еще не хватает некоторых основ, в частности, сертификатов SSL / TLS и их отношения к DNS.

Вот пример использования:

Я понимаю, что для этого есть две возможности:

  1. (для меня довольно ясно) Создайте перенаправление на уровне веб-сервера либо через nginx / apache: это означает, что оба домена все еще имеют свои собственные сертификаты SSL, но это просто вопрос написания некоторых строк в файле конфигурации, не имеющего отношения к любая конфигурация DNS.
  2. (здесь для меня все начинает усложняться) Попросите компанию, с которой мы работаем, предоставить нам информацию о КСО (https://en.wikipedia.org/wiki/Certificate_signing_request), чтобы мы могли сгенерировать файл CSR ... из закрытого ключа, который мы используем для создания наших собственных сертификатов SSL ...? Затем мы передаем CSR, и они платят за собственный SSL-сертификат. Затем они могут создать новый CNAME, который будет перенаправлять data.example.com. к ourdata.ourexample.com.. Мне сказали, что CSR - это своего рода открытый ключ, поэтому мы можем легко передать его кому-то другому. Но даже если это описание правильно описывает процесс, я честно не понимаю, что происходит, где и почему это делается.

Наконец, что я заметил в случае, когда CSR был сгенерирован с нашей стороны, а CNAME был создан, это то, что когда мы переходим к https://data.example.com, мы видим содержание https://ourdata.ourexample.com и URL-адрес, отображаемый в браузере, остается https://data.example.com. Я не уверен, связано ли это с какой-либо конфигурацией веб-сервера или с «настройками» DNS.

Я надеюсь, что то, что я описал, несколько ясно. Если нет, дайте мне знать, и я постараюсь предоставить более подробную информацию.

Примечание: я уже пытался найти некоторые ответы на этот вопрос, но, хотя я кое-что понял, это все еще не на 100% ясно.

Спасибо, SilentSib

Я предполагаю data.example.com будет размещен на ваш помещения и example.com не хочет, чтобы их клиенты видели, что вы предоставляете услуги.

Если это так, вам просто нужно два Apache виртуальные хосты или два nginx виртуальные серверы которые настроены для обслуживания одного и того же контента.

Что насчет сертификатов? Это не очень сложно, если вы понимаете концепции криптография с открытым ключом.

В основном (в одном из самых распространенных алгоритмов, ЮАР) у вас есть два ключа A и B. Данные зашифрованы с помощью A можно расшифровать только с помощью B (A не может его расшифровать) и наоборот. Вы раздаете одному из них называть его открытый ключ, другой держится в секрете и называется закрытый ключ. Открытый ключ используется для шифрования данных, которые можете расшифровать только вы, закрытый ключ также можно использовать для подписи: зашифровав заранее согласованную последовательность байтов (например, хеш сообщения) с помощью закрытого ключа, все остальные могут его расшифровать. и убедитесь, что у вас есть закрытый ключ.

Остальные части инфраструктура открытого ключа являются:

  • сертификаты: файл, содержащий ваш открытый ключ, ваше доменное имя и некоторые другие данные, подписанный доверенным закрытый ключ (чей открытый ключ распространяется и доверяет каждому браузеру). Только доменное имя есть в сертификате, а не другие данные из DNS (ну, вы можете попросить добавить свой IP-адрес в сертификат, если хотите), чтобы вам не приходилось менять их, когда что-то меняется.
  • CSR: почти то же самое, что и сертификат. Он содержит ваш открытый ключ, ваше доменное имя и некоторые другие данные, подписанные вашим закрытый ключ (чтобы показать, что у вас есть ключ). На практике центры сертификации используют только открытый ключ из CSR, а иногда и доменное имя (если они не берут его из HTML-формы).

Приватные ключи дешевы (пара секунд для генерации на загруженном сервере). Маловероятно, что ваш клиент использует тот же закрытый ключ для data.example.com и example.com (если оба имени не указаны в одном сертификате). Так:

  • Если у вашего клиента уже есть сертификат для data.example.com, попросите их отправить вам сертификат и соответствующий закрытый ключ (безопасным способом). Они больше не будут ими пользоваться,
  • Если у вашего клиента нет сертификата для data.example.com, создать новый закрытый ключ и заверить его. Не надо используйте закрытый ключ для других ваших доменов. Обычно новый закрытый ключ генерируется даже при обновлении сертификата. Если вы положите ourdata.example.net на том же сертификате все увидят, кто предоставляет data.example.com Сервисы.
  • Вы также можете использовать Давайте зашифровать если ваш клиент согласен с их условиями. Таким образом, вы можете получить действующий сертификат за считанные секунды и без дополнительных затрат.