Error ssl protocol error bitrix

Здравствуйте. Получил и установил SSL сертификат. Но при переходе на свой сайт, все равно не подключается по https.
Ubuntu 14.04. Vesta.
В терминале после получения сообщения «Congratulations! You have successfully enabled https://santria.ml», больше ничего не делал. Мб нужно что еще?
По пути: /etc/apache2/sites-available/ создался файл 000-default-le-ssl.conf, не работало, попробовал поменять название на доменное имя-le-ssl.conf не помогло.
При переходе на сайт выдает сообщение ERR_SSL_PROTOCOL_ERROR.
Если проверять по ссылке https://www.ssllabs.com/ssltest/analyze.html?d=san…

«Assessment failed: No secure protocols supported
Known Problems

There are some errors that we cannot fix properly in the current version. They will be addressed in the next generation version, which is currently being developed.

No secure protocols supported — if you get this message, but you know that the site supports SSL, wait until the cache expires on its own, then try again, making sure the hostname you enter uses the «www» prefix (e.g., «www.ssllabs.com», not just «ssllabs.com»).
no more data allowed for version 1 certificate — the certificate is invalid; it is declared as version 1, but uses extensions, which were introduced in version 3. Browsers might ignore this problem, but our parser is strict and refuses to proceed. We’ll try to find a different parser to avoid this problem.
Failed to obtain certificate and Internal Error — errors of this type will often be reported for servers that use connection rate limits or block connections in response to unusual traffic. Problems of this type are very difficult to diagnose. If you have access to the server being tested, before reporting a problem to us, please check that there is no rate limiting or IDS in place.
NetScaler issues — some NetScaler versions appear to reject SSL handshakes that do not include certain suites or handshakes that use a few suites. If the test is failing and there is a NetScaler load balancer in place, that’s most likely the reason.
Unexpected failure — our tests are designed to fail when unusual results are observed. This usually happens when there are multiple TLS servers behind the same IP address. In such cases we can’t provide accurate results, which is why we fail.»

0

1

ServerTokens OS
ServerRoot "/etc/httpd"
PidFile run/httpd.pid
Timeout 120
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15
#Listen 443
<IfModule worker.c>
StartServers         2
MaxClients          30
MinSpareThreads     25
MaxSpareThreads     75
ThreadsPerChild     25
MaxRequestsPerChild  1500
</IfModule>

LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule include_module modules/mod_include.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule logio_module modules/mod_logio.so
LoadModule env_module modules/mod_env.so
LoadModule ext_filter_module modules/mod_ext_filter.so
LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule info_module modules/mod_info.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule dir_module modules/mod_dir.so
LoadModule actions_module modules/mod_actions.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule ssl_module modules/mod_ssl.so

Include conf.d/*.conf

User bitrix
Group bitrix

ServerAdmin root@localhost

UseCanonicalName Off

DocumentRoot "/home/bitrix/www"

<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>

<IfModule mod_userdir.c>
    UserDir disable
</IfModule>

DirectoryIndex index.html index.html.var

AccessFileName .htaccess

<Files ~ "^.ht">
    Order allow,deny
    Deny from all
</Files>

TypesConfig /etc/mime.types
DefaultType text/plain
<IfModule mod_mime_magic.c>
#   MIMEMagicFile /usr/share/magic.mime
    MIMEMagicFile conf/magic
</IfModule>

HostnameLookups Off
ErrorLog logs/error_log
LogLevel warn
LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined
LogFormat "%h %l %u %t "%r" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
CustomLog logs/access_log combined
ServerSignature On

<IfModule mod_dav_fs.c>
    # Location of the WebDAV lock database.
    DAVLockDB /var/lib/dav/lockdb
</IfModule>

IndexOptions FancyIndexing VersionSort NameWidth=* HTMLTable

IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

AddLanguage ca .ca
AddLanguage cs .cz .cs
AddLanguage da .dk
AddLanguage de .de
AddLanguage el .el
AddLanguage en .en
AddLanguage eo .eo
AddLanguage es .es
AddLanguage et .et
AddLanguage fr .fr
AddLanguage he .he
AddLanguage hr .hr
AddLanguage it .it
AddLanguage ja .ja
AddLanguage ko .ko
AddLanguage ltz .ltz
AddLanguage nl .nl
AddLanguage nn .nn
AddLanguage no .no
AddLanguage pl .po
AddLanguage pt .pt
AddLanguage pt-BR .pt-br
AddLanguage ru .ru
AddLanguage sv .sv
AddLanguage zh-CN .zh-cn
AddLanguage zh-TW .zh-tw

###LanguagePriority en ca cs da de el eo es et fr he hr it ja ko ltz nl nn no pl pt pt-BR ru sv zh-CN zh-TW

###ForceLanguagePriority Prefer Fallback

AddDefaultCharset UTF-8

AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz

AddHandler type-map var
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4.0b2;" nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4.0" force-response-1.0
BrowserMatch "Java/1.0" force-response-1.0
BrowserMatch "JDK/1.0" force-response-1.0

<Location /server-status>
        SetHandler server-status
        Allow from 127.0.0.1
        Order deny,allow
        Deny from all
</Location>
ExtendedStatus On

NameVirtualHost *:80
Listen 80
ServerName site_name.com
<VirtualHost site_name.com>
        ServerAdmin webmaster@localhost
        DocumentRoot /home/bitrix/www/site_name
        ServerName site_name.com
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>

        <Directory /home/bitrix/www>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                DirectoryIndex index.php index.html index.htm
                Order allow,deny
                allow from all
        </Directory>

        ErrorLog logs/error_log
        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

###     CustomLog logs/access_log combined

    <IfModule mod_rewrite.c>
    #Nginx should have "proxy_set_header HTTPS YES;" in location
    RewriteEngine On
    RewriteCond %{HTTP:HTTPS} =YES
    RewriteRule .* - [E=HTTPS:on,L]
    </IfModule>

</VirtualHost>

<IfModule mod_ssl.c>
NameVirtualHost *:443

Listen 443
<VirtualHost *:443>
        <Directory /home/bitrix/www>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                DirectoryIndex index.php index.html index.htm
                Order allow,deny
                allow from all
        </Directory>
        <Directory /home/bitrix/www/site_name>
                AllowOverride All
        </Directory>
        DocumentRoot /home/bitrix/www/site_name
        ServerName site_name.com

        SSLEngine on
        SSLProtocol all -SSLv2
        SSLCertificateFile /etc/pki/tls/certs/ca.crt
        SSLCertificateKeyFile /etc/pki/tls/private/ca.key
</VirtualHost>
</IfModule>

<IfModule mod_ssl.c>
NameVirtualHost *:443

Listen 443
<VirtualHost *:443>

<IfModule mod_ssl.c>
NameVirtualHost site_name.com:443

Listen 443
<VirtualHost site_name.com:443>

После установки SSL сертификата в битриксе на виртуальной машине BitrixVM версии 7.4.1 начала появляться ошибка с сокетами, при этом если перейти на сайт по обычному http, то такой проблемы не наблюдается.
Ниже описано как решить данную проблему с сокетами при использование SSL сертификата и протокола HTTPS в Bitrix virtual appliance version 7.4.1 («1С-Битрикс: Веб-окружение»).

Открываем SSH клиет (PuTTY).
Если меню битрикса не отображается сразу, то заходим в меню следующей командой:

cd
./menu.sh

Затем выбираем поочередно пункты в меню:

8. Manage pool web servers
3. Configure certificates
2. Configure own certificate

Если данных пунктов у вас нет, то сначала нужно обязательно создать пул:
1. Create Management pool of server

После того, как зашли в пункт 2. Configure own certificate, указываем сайт или оставляем по умолчанию Enter site name (default):

Указываем:
Private Key path: /etc/nginx/ssl/cert.key
Certificate path: /etc/nginx/ssl/cert.crt
Certificate Chain path: /etc/nginx/ssl/cert_ca.crt

Пути заменяем на свои, либо предварительно запишите файлы сертификатов с такими именами по таким же путям. 

После вопроса Please confirm you want to update certificate settings for the sites (N|y): вводим Y и нажимаем enter.

Готово, сайт должен открываться по HTTPS, но у меня не работало, поскольку я не указывал Certificate Chain path, у меня не было сертификатов для цепочки (промежуточных) и пока я не указал эти сертификаты в Certificate Chain path у меня SSL не работал. Точнее сам сайт по HTTPS открывался нормально в защищённом режиме, но в проверке системы битрикс показывалась ошибка с сокетами: 
Ошибка! Работа с сокетами (check_socket): Fail Connection to ssl://site.com:443 Fail, Connection to ssl://site.com:443 Fail Socket error [0]: 
Подробности ошибки указаны в журнале проверки системы.

Также если обратится к сайту в консоли через curl командой:
curl https:// site.com :443
выходило следующие curl: (60) Peer’s Certificate issuer is not recognized.
При нормальной работе должен показываться HTML код сайта. 

Проблема еще была в том, что у меня не было никаких промежуточных сертификатов, а только публичный сертификат (CRT) и приватный ключ (Private KEY).

Центр сертификации мне больше ничего не выдавал, а точнее хостинг где я их покупал.
Техподдержка не отвечала, у них были праздничные выходные. 

Как же их получить? 
Нашёл решение такое, открываем сайт в браузере Firefox, нажимаем на замочек, затем на стрелку справа от зеленной надписи «Защищенное соединение», затем внизу «Подробнее».
После чего откроется окно «Информация о странице». Там нажимаем «Просмотреть сертификат».
Откроется страница с различными данными и параметрами сертификата. Находим ниже ссылки Загрузить PEM (сертификат) и PEM (цепочка сертификатов). Именно последний нам и нужен. Качаем PEM (цепочка сертификатов).

Формат PEM я переименовал в CRT. У меня сработало с ним, но возможно и с PEM сработает. 
После того как я указал этот chain сертификат, как указано выше в Certificate Chain path, у меня наконец-то пропала ошибка с сокетами и все наконец стало работать как надо. 

Записи о сертификатах создаются в файле:
/etc/nginx/bx/site_avaliable/ssl.s1.conf 

там указано где хранятся сертификаты:
ssl_certificate   /etc/nginx/certs/default/cert.crt;
ssl_certificate_key  /etc/nginx/certs/default/cert.key;
ssl_trusted_certificate /etc/nginx/certs/default/cert_ca.crt;

Также данные записи были сделаны в файле /etc/nginx/bx/conf/ssl-push-custom.conf
А изначально настройки брались из /etc/nginx/bx/conf/ssl.conf

В документации вообще сказано, что для сайта по умолчанию s1 (который находится в директории /home/bitrix/www) файл будет называться /etc/nginx/bx/site_avaliable/s1.ssl.conf, а для дополнительных сайтов (которые создаются в директории /home/bitrix/ext_www/название_хоста) — /etc/nginx/bx/site_avaliable/bx_ext_ssl_название_хоста.conf.

Поэтому нужный файл конфигурации здесь еще нужно постараться определить.

Не забываем также указать в файле /etc/hosts ваш IP и домен. я указал два ip версии 4 и 6, а также 127.0.0.1 localhost

После правок нужно выполнить команду 
nginx  -t
И перезагрузить 
service nginx restart или # /etc/init.d/nginx restart

Если нужно установить бесплатный сертификат LetsEncrypt, об это написано в этой статье Установка SSL сертификата LetsEncrypt на BitrixVM

Загрузка

Ошибка сертификата при открытии сайта с уcтройства Android

Андройд ругается на ssl сертификат.

С этого поста я начинаю свой блог. Писать я особо не умею, но решил написать данный пост т.к. решил актуальную проблему, а в инете решения четкого нет. Искал решение как побороть ошибку подключения ssl на андроид, часа три и все же с миру по нитке насобирал какие-то ответы на свои вопросы, а главное решил задачу.

Итак, у меня была ситуация, когда заказчику надоел свой хостер timeweb (главная причина медленная и тупая тех поддержка) и поставил он на меня задачу найти подходящий сервер для своего интернет магазина на битрикс, главные критерии — быстрота работы и адекватная поддержка . И конечно же все остальное:

• Размер жесткого диска 30Г+
• Тестовый период
• Web сервер apache + nginx – это лучшая связка под битрикс
• Php как модуль apache – лучшая производительность
• Доступ по SSH
• Адекватная техническая поддержка
• Возможность увеличивать CPU, RAM и HDD, без смены тарифа

Выбор пал на ispserver. Заказал обычный виртуальный хостинг, для теста, но как выяснилось, он не подходит для нашего проекта, по тому как для корректной работы битрикс необходимо изменение многих директив и модулей php и самого сервера, а изменить или добавить подобные параметры нет возможности, так как они общие для всех клиентов, по крайней мене так заявил сам хостер.

Попросил для теста Виртуальный выделенный сервер VDS. Как оказалось, после теста — хороший хостинг, подходит по всем параметрам. Настроил сервер под проект, перенес сайт.

Задача осталась за малым — перенести ssl сертификат с таймвеба. Скопировал с сервера все нужные файлы, а именно

• сертификат в формате xxx_a9e57_2bd75_1491868799_c5…10.crt
• и ключ к нему в формате a9e57_2bd75_2b…2e.key

В isp manager создал новый существующий сертификат.

И еще, как в последствии оказалось, в файле конфигурации (у меня Centos7 поэтому /etc/httpd/conf/vhosts/www-root/site.ru) прописать, чтобы обращение к сайту было по 443 порту. Просто добавить запись ServerName site.ru:443 И все заработало.
Спустя как время, после проверки на усройстве с Андройд, во всех браузерах начала появляться ошибка подлинности сертификата и другие ошибки:

• Идентификационные данные этого сайта не проверены
• Сертификат сервера не является доверенным
• Соединение с сервером зашифровано с помощью устаревших наборов шрифтов
• Ваше соединение не защищено
• Владелец неправильно настроил свой веб-сайт
• Злоумышленники могут пытаться похитить ваши данные с сайта
• NET::ERR_CERT_COMMON_NAME_INVALID
• err ssl protocol error на телефоне андроид

И так далее и тому подобное.

Самое интересное, что десктопные компьютеры открывают сайт как положено, а браузеры на Android, в частности Сhrom, Yandex и Opera, выдают ошибку на ssl сертификат.

Долгое время искал ответ на вопрос.

После выполнения следующей команды в консоли сервера под Centos 7, выяснилось что проблема на стороне сервера, а не в андройде или браузее как могло показаться.

openssl s_client -connect site.ru:443
CONNECTED(00000003)
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = site.ru
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = site.ru
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = site.ru
verify error:num=21:unable to verify the first certificate
verify return:1
---

Данные ошибки свидетельствуют о том, нет сертификата удостоверяющего центра.

В итоге проблема оказалась в том, что — пропушенная тогда цепочка сертификатов, оказалась всему виной.

Как я решил проблему.

Открыл сайт на десктопе в на иконке замка рядом с доменом, после надписи Защищенное соединение нажал ссылку подробнее. (или F12) В открывшемся внизу консоли во вкладке Security нажал view certificate и во вкладке Путь сертификации моему взору открылись все промежуточные центры сертификации до корневого. Осталось составить цепочку из этих центров сертификации.

Значит выделяем предыдущий центр, который следует до вашего сертификата, нажимаем «Просмотр сертификата» и во вкладке «Состав» находим открытый ключ и копируем его в файл при помощи одноименной кнопки. У меня не сразу получилось это сделать, но если потыкать и подключить сообразительность минут 10 и у вас все получится.

И так мы сохраняем все сертификаты у каждого промежуточного центра вплоть до корневого.

Далее составляем цепочку сертификатов.

В поле «Цепочка сертификатов», при создании сертификата в isp manager (или ispmgr), сначала необходимо вставить сертификаты всех промежуточных центров и в конце главного корневого центра. Обратите особое внимание на то, что один идет сразу после другого с новой строки в порядке того, кем выдавался сертификат и без пробелов. Конечно не забудьте, заполнить поля «Сертификат» и «Приватный ключ»

После сохранения и применения данного сертификата к вашему доменному имени в браузерах под андройд Ваш сайт будет открываться без ошибок, так получилось и у меня. Доволен и я и заказчик. Желаю вам справиться с этой несложной задачей.

Краткое руководство о том, как исправить ошибку в Chrome «Этот сайт не может обеспечить безопасное соединение» или «ERR_SSL_PROTOCOL_ERROR».

Если Google Chrome – ваш основной доступ в мир интернета, вы должны были хотя бы раз столкнуться с ошибкой «Этот сайт не может обеспечить безопасное соединение» или уведомлением об ошибке ERR_SSL_PROTOCOL_ERROR. В целом это описывает ряд ошибок, что вызывает разочарование, так как в большинстве случаев нет легко распознаваемой причины. Ошибки SSL могут появляться как на самых популярных сайтах, так и на самых менее посещаемых.

Как мы только, что обсуждали, что касается причины, по которой Google иногда говорит: «Этот сайт не может обеспечить безопасное соединение», то практически невозможно связать ее с одной причиной. Это может быть что угодно, от такой тривиальной проблемы, как неправильная дата в системе, до гораздо более сложных проблем с сервером.

Шаги по устранению неполадок, чтобы исправить ERR_SSL_PROTOCOL_ERROR в Google Chrome. Если какой-то не помог, попробуйте следующий совет.

ERR_SSL_PROTOCOL_ERROR дата и время  

Касаемо сбитой даты и времени, по последним данным ошибка будет именно ERR_CERT_DATE_INVALID

В этом случае неправильные настройки даты и времени могут вызывать у вас проблемы. Итак, убедитесь, что ваша система не отстает и не забегает вперед. Почему это проблема? Срок действия ssl сертификата является чрезвычайно важным фактором в процессе аутентификации, а это означает, что нужно держать очень конкретные вкладки, указывающие время подписи сертификата и срок его действия. Если есть проблема с временем и датой вашей системы, это может вызвать всевозможные проблемы во время аутентификации. Эти браузеры спроектированы так, чтобы проявлять осторожность, поэтому такая простая вещь, как неправильное время, может вызвать ошибку SSL-соединения. 

ERR_SSL_PROTOCOL_ERROR очистка данных браузера Chrome

От одного очевидного решения к другому.

Если у вас правильная дата и время на устройстве, пора очистить кеш и файлы Cookie в Google Chrome. Для этого нажмите Ctrl + Shift + Delete и удалите данные из истории браузера. В целом мы рекомендуем почаще чистить эти данные. 

ERR_SSL_PROTOCOL_ERROR очистка состояния SSL 

Если ничего из вышеперечисленного не работает, следующее, что вам следует попробовать, — это очистить состояние SSL. Для этого выполните следующие действия: 

    1. Сначала перейдите в раздел «Настройка и управление Google Chrome» — три точки, которые вы видите чуть ниже кнопки закрыть. 

    2. Теперь нажмите «Настройки». 

    3. Прокрутите страницу вниз и откройте Дополнительные настройки. 

    4. Перейдите к разделу «Открыть настройки прокси», прокрутив вниз или выполнив поиск в строке поиска. 

    5. Откроется окно с названием «Свойства Интернета». 

    6. Перейдите в окно содержимого и нажмите кнопку «Очистить состояние SSL». 

Исправление этой ошибки по-средством отключения протокола QUIC

QUIC (Quick UDP Internet Connections) обеспечивает подключение к серверам Google, эквивалент TLS/SSL. По умолчанию в Chrome включен протокол QUIC. 

Чтобы отключить его, скопируйте chrome: // flags / # enable-quic (без пробелов) и вставьте его в адресную строку, нажмите Enter. В верхней части экрана установлен по умолчанию протокол QUIC. Отключите его и перезапустите Chrome.

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

Проверьте настройки антивируса

Предупреждение: этот шаг не совсем безопасен, поскольку он разрешает использовать старые и небезопасные протоколы SSL/TLS, которые все еще используются на некоторых веб-сайтах.

Возможно, вы этого не знаете, но ваше антивирусное программное обеспечение следит за веб-страницами, которые вы посещаете, и защищает вас от любых угроз, которые они могут представлять или содержать. Это делается путем проверки протокола SSL/TLS, который использует веб-сайт. Если протокол окажется небезопасным и устаревшим, он не позволит вам посетить сайт.

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

Примечание 

Обычно причина того, что антивирусная программа вызывает тревогу о соединении SSL/TLS, заключается в том, что сервер пытается установить соединение, используя устаревшую или уязвимую версию SSL или TLS, такую ​​как SSL 3.0 или TLS 1.0. 

Включите все версии SSL/TLS — как последний шаг

Предупреждение: этот шаг не совсем безопасен, поскольку он позволяет использовать старые и небезопасные протоколы SSL/TLS, которые все еще используются на некоторых веб-сайтах.

Когда вы посещаете веб-сайт с SSL соединением, он использует протоколы SSL/TLS для связи с сервером. Иногда версия веб-сайта SSL/TLS может быть несовместима с вашей версией браузера Chrome, поскольку Chrome по умолчанию не разрешает запуск устаревших протоколов SSL/TLS. Следовательно, вам нужно изменить эти настройки протокола SSL/TLS:

    1. Нажмите на три точки, которые вы видите в правом верхнем углу Chrome, и нажмите «Настройки».

    2. Теперь прокрутите вниз и перейдите к дополнительным настройкам.

    3. Найдите настройки прокси и откройте его.

    4. Нажмите на Advanced (расширенные настройки)

    5. Прокрутите вниз, пока не появится раздел Безопасность. Теперь убедитесь, что вы подключили все версии SSL и TLS.

    6. Щелкните Применить.

    7. Перезапустите Chrome. 

Примечание 

Считайте этот совет теоретическим. Все основные браузеры объявили о планах отключить поддержку всех предыдущих версий TLS, сохранить TLS 1.2 и недавно опубликованный TLS 1.3. Это делается из соображений безопасности. Не включайте поддержку устаревших версий TLS и SSL с известными уязвимостями. Никакая законная организация не попросит вас нарушить настройки безопасности вашего браузера для взаимодействия с их веб-сайтом.

Мы надеемся, что это руководство помогло вам исправить сообщения ERR_SSL_PROTOCOL_ERROR  в браузере Chrome. А если нет, поделитесь комментариями к этой статье и мы постараемся помочь вам с этим.