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

Как услуги SaaS предоставляют SSL для людей с «персонализированными» доменами?

Итак, я обсуждал с другом о веб-сайтах SaaS и сертификатах SSL, и никто из нас не мог объяснить, как электронная коммерция или любой другой сервис, который позволил бы клиенту иметь свои собственные домены, имели бы услуги с поддержкой SSL.

Я искал сертификаты UCC и Wildcard, но, похоже, ни один из них не соответствует потребностям, потому что в случае сертификата UC вам потребуется список уже созданных доменов (что не относится к модели SaaS) и в В случае подстановочного сертификата вам обязательно потребуется сделать каждого клиента поддоменом, и многие службы предоставляют возможность использовать ваш собственный домен.

Так как же сервисы SaaS предоставляют SSL для людей с «персонализированными» доменами?

Приведенный выше ответ может быть немного устаревшим. Современные приложения SaaS, которые хотят обслуживать SSL для нескольких клиентских доменов, будут использовать SNI. SNI - это «указание имени сервера» (RFC 6066; устаревшие RFC 4366, RFC 3546) - это расширение Transport Layer Security, которое позволяет клиенту сообщать серверу имя хоста, которого он пытается достичь.

Это намного эффективнее, чем старые способы решения этой проблемы, такие как UCC или, что еще хуже, 1 IP на сертификат. Вот почему традиционно защита пользовательских доменов - это затраты, которые ложатся на плечи клиента. Было и довольно часто можно увидеть, что платформа взимает X долларов в месяц за пользовательские домены в качестве дополнительной функции. Это из-за затрат, связанных с использованием пользовательских доменов.

Если вы хотите разработать что-то подобное сегодня, вы должны начать с SNI и таким образом предоставлять сертификаты. В зависимости от вашего стека это может быть очень просто (NodeJS) или очень сложно (традиционные прокси-серверы приложений на основе apache / nginx). Обычно трудность заключается в том, чтобы принять входящий запрос SNI и сопоставить его с вашей базой данных или другой логикой приложения, чтобы убедиться, что вы обслуживаете правильный сертификат для этого запроса.

Как уже упоминалось, вам может повезти, если вы используете Node. Есть несколько отличных библиотек, которые помогают в этом, если вы хотите обслуживать сертификаты, предоставляемые Let's Encrypt, и хотите динамически предоставлять сертификат на основе данных во входящем запросе. Например https://git.coolaj86.com/coolaj86/greenlock.js - это библиотека, которая поможет вам в этом.

Наконец, если вы ищете стороннее решение, есть https://clearalias.com, который в основном позволяет вам обойти трудности обслуживания SSL-сертификатов SNI, предлагая их как услугу, если вы не особенно заинтересованы в управлении и поддержании собственного уровня SNI.

Обычно они используют сертификаты UCC SSL, что позволяет им защищать несколько доменных имен с помощью альтернативных имен субъектов. Вы можете перевыпустить сертификат с обновленным списком доменов, которые он защищает, поэтому вы не ограничены только доменами, которые вы защищаете при первом создании сертификата.

У некоторых поставщиков есть продукты, специально предназначенные для этого, например Globalsign: https://www.globalsign.com/cloud/ который используется Cloudflare.

Как провайдер вы могли бы просто создать один SSL-сертификат для каждого своего клиента с доменами и поддоменами, которые им нужны, и выпустить его повторно, если клиент удалил определенный домен из своей учетной записи. Как поставщик SaaS вы обычно также контролируете настройку сертификатов SSL, поэтому практически все можно автоматизировать.