При интеграции мобильных приложений с 1С часто возникает ситуация, когда разработка ведется внутри локальной сети предприятия. Использование протокола HTTPS становится обязательным требованием современных мобильных операционных систем и сторонних API. Однако при попытке использовать самоподписанные сертификаты или обращении по локальному IP-адресу (например, 192.168.1.165) разработчики сталкиваются с ошибками типа ERR_SSL_PROTOCOL_ERROR. В этой статье мы подробно разберем, как правильно организовать архитектуру безопасного соединения, чтобы мобильные устройства Android и iOS доверяли вашему серверу 1С.
Проанализируем сначала причины, по которым обычного создания сертификата через OpenSSL бывает недостаточно. Современные мобильные платформы предъявляют жесткие требования к безопасности:
network_security_config.xml. Если вы не являетесь разработчиком мобильного клиента, «подсунуть» ему самоподписанный сертификат практически невозможно.Common Name (CN). Если вы обращаетесь по IP-адресу, этот адрес обязательно должен быть прописан в поле SAN сертификата.Это самый «чистый» и профессиональный способ. Рассмотрим ситуацию: у вас нет «белого» IP-адреса, и сервер 1С находится за NAT. Вы можете получить настоящий доверенный сертификат от Let’s Encrypt, используя проверку через DNS.
Разберем этот метод по шагам:
1c.vash-magazin.ru).DNS-01 Challenge. Для этого при запросе сертификата (через Certbot или аналоги) вам нужно будет добавить специальную TXT-запись в настройки вашего DNS-провайдера. Это подтвердит, что вы владеете доменом, даже если сервер не виден из интернета.Apache. Чтобы мобильные устройства в локальной сети находили сервер по имени 1c.vash-magazin.ru, настройте внутренний DNS-сервер на роутере или отредактируйте файл hosts (если это возможно), сопоставив домен с локальным IP 192.168.1.165.В результате мобильное приложение обращается по реальному доменному имени, получает валидный сертификат, и цепочка доверия полностью подтверждается.
Если настройка DNS и проброс портов кажутся слишком сложными, рассмотрим технологию туннелирования. Это позволяет вывести локальный сервис в интернет по защищенному каналу без покупки статического IP.
Выясним, как это работает:
Вы устанавливаете на компьютер с 1С небольшую утилиту cloudflared. Она создает исходящее соединение с сервером Cloudflare. В панели управления Cloudflare вы привязываете свой домен к этому туннелю. Теперь ваш адрес https://1c.yourdomain.com будет вести прямиком на ваш локальный Apache. Cloudflare автоматически предоставит SSL-сертификат, которому доверяют все устройства в мире.
Если вы все же решили использовать самоподписанные сертификаты для внутренней сети, мы рекомендуем отказаться от стандартных команд OpenSSL и использовать утилиту mkcert. Она автоматически создает ваш собственный локальный удостоверяющий центр (CA).
Рассмотрим процесс настройки:
mkcert на сервер.mkcert 192.168.1.165 localhost server.local..pem и .key, которые полностью соответствуют современным стандартам (включая SAN).mkcert, нужно будет установить на каждое мобильное устройство и подтвердить доверие к нему.После того как сертификаты получены (любым из способов), их необходимо правильно прописать в конфигурационном файле httpd.conf или httpd-ssl.conf вашего Apache. Посмотрим на пример настройки:
<VirtualHost *:443>
ServerName 1c.vash-magazin.ru
DocumentRoot "C:/Apache24/htdocs"
SSLEngine on
# Путь к файлу сертификата
SSLCertificateFile "conf/ssl/cert.pem"
# Путь к файлу закрытого ключа
SSLCertificateKeyFile "conf/ssl/key.pem"
# Если используется Let's Encrypt, укажите цепочку сертификатов
# SSLCertificateChainFile "conf/ssl/fullchain.pem"
<Directory "C:/Apache24/htdocs">
AllowOverride All
Require all granted
</Directory>
# Проброс запросов к 1С (пример для публикации)
ManagedRuntimeControl On
</VirtualHost>
Обратите внимание, что директива SSLEngine on включает шифрование. Проверьте, что модуль mod_ssl раскомментирован в основном файле конфигурации httpd.conf.
Часто программисты 1С находят более удобным использование Nginx в качестве «входных ворот». Он проще в настройке SSL и может перенаправлять запросы на Apache по обычному HTTP (порт 80) внутри одной машины. Это называется терминированием SSL.
Проанализируем конфигурацию Nginx для такой схемы:
server {
listen 443 ssl;
server_name 1c.vash-magazin.ru;
ssl_certificate /etc/letsencrypt/live/1c.vash-magazin.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/1c.vash-magazin.ru/privkey.pem;
location / {
proxy_pass http://127.0.0.1:80; # Передаем запрос на Apache
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Такой подход позволяет централизованно управлять сертификатами и легко обновлять их с помощью автоматических скриптов (например, certbot), не затрагивая настройки публикации базы 1С в Apache.
Если после настройки вы все еще видите ошибку ERR_SSL_PROTOCOL_ERROR, выполните следующие проверки:
1c.vash-magazin.ru, а вы в приложении вводите https://192.168.1.165/..., проверка безопасности не пройдет. Адрес в приложении должен строго совпадать с именем в сертификате.Подводя итог, можно сказать, что наиболее стабильным и «правильным» решением для магазина с несколькими планшетами является Вариант 1 (Реальный домен + DNS-проверка) в сочетании с настройкой локального DNS на роутере. Это избавит вас от необходимости вручную настраивать каждое мобильное устройство и обеспечит бесперебойную работу HTTP-сервисов 1С.