Безопасный сайт или HTTPS

Строго говоря, https не является отдельным протоколом. По сути это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS. Это обеспечивает защиту от атак, основанных на прослушивании сетевого соединения — от снифферских атак, но не защищает от атак типа man-in-the-middle.

По умолчанию https: URL использует 443 TCP-порт (для незащищённого HTTP — 80). Чтобы подготовить веб-сервер для обработки https соединений, администратор должен получить и установить в систему сертификат для этого веб-сервера. Сертификат состоит из двух частей (двух ключей) — public и private. Public часть сертификата используется для зашифровывания трафика от клиента к серверу в защищённом соединении, private часть — для расшифровывания полученного от клиента зашифрованного трафика на сервере. Сертификат можно получить в компании-сертификаторе (например, VeriSign). Естественно, это стоит денег. Сертификат должен быть подписан уполномоченной стороной (компанией-сертификатором — Certificate authority), которая будет гарантировать клиентам, что держатель сертификата является тем, за кого себя выдаёт.

Некоторые сайты используют собственные сертификаты. Существует возможность создать такой сертификат, не обращаясь в компанию-сертификатор. Такие сертификаты могут быть созданы для серверов, работающих под Unix, с помощью таких утилит, как ssl-ca от OpenSSL [1] или gensslcert от SuSE. Подписываются такие сертификаты этим же сертификатом и называются self-signed. Такие сертификаты менее надёжны, чем сертификаты подписанные компаниями-сертификаторами. Такое использование защищает от пассивного прослушивания, но без проверки сертификата каким-то другим способом (например, звонок владельцу и проверка контрольной суммы сертификата) этот метод не будет являться вполне безопасным.

Эта система также может использоваться для аутентификации клиента, чтобы обеспечить доступ к серверу только авторизированным пользователям. Для этого администратор обычно создаёт сертификаты для каждого пользователя и загружает их в браузер каждого пользователя. Также будут приниматься все сертификаты, подписанные организациями, которым доверяет сервер. Такой сертификат обычно содержит имя и адрес электронной почты авторизованного пользователя, которые проверяются при каждом соединении, чтобы проверить личность пользователя без ввода пароля.

В HTTPS для шифрования используется длина ключа 40, 56, или 128 бит. Старые версии браузеров использует длину ключа 40 бит (пример тому — IE), что связано с экспортными ограничениями в США. Длина ключа 40 бит не является сколько-нибудь надёжной. Многие современные сайты требуют использования новых версий браузеров, поддерживающих шифрование с длиной ключа 128 бит с целью обеспечить достаточный уровень безопасности. Такое шифрование значительно затрудняет злоумышленнику поиск паролей и другой личной информации

проблемы после перехода на https

Мой хостер теперь дает возможность

Это не хостер давать должен. Вы сами можете установить протокол.

но также учитывайте, что по сути сайт будет переиндексирован.

 
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:SSL} !=1 [NC]
RewriteRule ^(.*) https://www.сайт.com/$1 [L,R=301]
 

RewriteEngine On
RewriteCond %{HTTPS} =off 
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L]

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

А если все страницы с http будут перенаправляться на https, разве это вызовет какие-то проблемы с индексированием?

Хостер ответил, что работа такого редиректа зависит от того как настроена работа по https в самой CMS

Добавьте в .htaccess этот код, а всё остальное, из того, что Вы написали, уберите:

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]