Содержание
- 5 Ways to Fix SSL_ERROR_SYSCALL
- SSL_ERROR_SYSCALL Error
- Understanding SSL_ERROR_SYSCALL Error
- Restart the computer
- Modify Git network configuration
- Change HTTP/HTTPS encryption library
- Use HTTPS proxy for git connection
- Use SSH for git connection
- Solve Postgres error “Error: SSL SYSCALL error: EOF detected”
- Make the queries run faster
- Adjust the connection timeout
- PostgreSQL: ошибка SSL SYSCALL: обнаружен EOF
- Ошибка Postgres SSL SYSCALL: обнаружен EOF с помощью python и psycopg
- Генератор данных реального мира 1
- Ошибка SSL_read с ошибкой SSL_ERROR_SYSCALL
5 Ways to Fix SSL_ERROR_SYSCALL
SSL_ERROR_SYSCALL typically occurs when the server side is using an SSL certificate to authenticate. This article covers how to fix SSL_ERROR_SYSCALL error in 5 ways.
SSL_ERROR_SYSCALL Error
$ git clone https://github.com/xxx/xxx.git
fatal: unable to access ‘https://github.com/xxx/xxx.git/’: LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443
Understanding SSL_ERROR_SYSCALL Error
This error typically occurs when the TCP three-way handshake between client and server completes but then a TCP reset packet (often written as “RST”) is received by the client, terminating the connection during the SSL phase.
This error is not produced when a client receives a RST packet during the three-way handshake, or after completion of the SSL/TLS negotiation (SSL phase).
Restart the computer
As we all know, restarting solves 90% of problems, and sometimes restarting the computer can directly solve the problem.
Modify Git network configuration
We can directly modify the global Git configuration file and delete the relevant configuration of HTTP / HTTPS in the file.
It can also be modified using the command:
- $ git config –global –unset http.proxy
- $ git config –global –unset https.proxy
Change HTTP/HTTPS encryption library
Since the problem is that the LibreSSL library reports an error, we can modify Git to use the OpenSSL library for HTTPS communication.
$ git config –global http.sslBackend “openssl”
Use HTTPS proxy for git connection
When using HTTPS to connect to GitHub for push/pull, we need to change the local git configuration and use a proxy to initiate a request to GitHub.
Execute the following command: $ git config –global -e
This will bring us into git’s configuration file editing interface (which will open with the default editor specified by git). Add the following to this file:
[http]
proxy = socks5://127.0.0.1:7891
[https]
proxy = socks5://127.0.0.1:7891
“7891” is the designated entry and exit port of our proxy software, please modify it according to the actual situation.
Use SSH for git connection
It is well known that HTTPS or SSH can be used to clone the GitHub repository, but SSH does not have the network connection problem of HTTPS, so the connection method of push/pull can be changed from HTTPS to SSH.
Requirements: we need to generate an SSH public/private key pair in advance and add the public key to our GitHub account. See Connecting to GitHub with SSH for details on this part .
Enter the corresponding directory of the warehouse and execute the following command: $ git remote set-url origin git@github.com:xxx/xxx.git
After the change is complete, we can use the following command to view the current origin address:
Источник
Solve Postgres error “Error: SSL SYSCALL error: EOF detected”
I was running a scraping job from a Docker container using Python and the psycopg2 adapter that wrote the results to a Postgres database managed on DigitalOcean (DO). On random occasions, the container died, for some reason. I started debugging and these are my findings.
The error I ran into was the following:
I literally had no idea what to expect when Googling this error. Here’s what I found.
Make the queries run faster
It tends to happen with Postgres deployments that have very little RAM allocated to them. For example, I’m using the cheapest Postgres hosting on DO, it only has 512mb of memory attached to it .
In other words: the lower the memory, the longer it takes to run complex queries, with a higher probability that the connection times out.
If you can spare the bucks: add more memory.
Adjust the connection timeout
If adding more memory is not an option, try changing the keepalives parameters of your Postgres connection. For example, in psycopg2, you can do that as follows.
Let’s go over these four parameters quickly:
- keepalives (boolean): By setting this to 1, you indicate you want to use your own client-side keepalives.
- keepalives_idle (seconds): Sets the number of seconds of inactivity after which a keepalive message such be sent.
- keepalives_interval (seconds): Sets the number of seconds to wait before resending a message that has not been acknowledged by the server.
- keepalives_count (count): Sets the number of non-acknowledged keepalives to determine that the connection is dead.
So, solve the problem by making your queries run faster, or by making sure your connection doesn’t time out.
Источник
PostgreSQL: ошибка SSL SYSCALL: обнаружен EOF
Во-первых, я искал и нашел несколько сообщений, касающихся этой ошибки, и большинство из них указывают либо на проблему с ОЗУ, либо на проблему с SSL, я попытался преодолеть возможность SSL, добавив в командной строке sslmode = disabled:
Но появилось то же сообщение:
Что касается возможной проблемы с памятью, я не знаю, как ее устранить.
Структура данных — та, которая описана в этом вопросе, и, как вы, возможно, обнаружите, это будет очень длительный запрос, чтобы завершить достижение полной таблицы изменения для всех унаследованных таблиц.
Обновление 2017-06-01 13:50 GMT
Изменена команда на (из-за рекомендаций @ Daniel Vérité):
Проблема фактически изменилась на следующее:
Обновление 2017-06-01 15:34 GMT
Найдено несколько записей в журнале (в /var/log/postgresql/postgresql-9.4-main.log ), как эти:
Поэтому я продолжу с предложенной подсказкой.
Также найдена эта группа записей, которые фактически ссылаются на сбой и последующее восстановление:
Любые предложения по этой последней части журнала?
OOM Killer включен, и следующий вывод /var/log/messages :
Обновление 2017-06-01 16:19 GMT
Изменены настройки на:
И я заполнил жесткий диск 🙁 Я щедро увеличил checkpoint_segments, но сначала не проверил доступное пространство. К счастью, я тестирую эту процедуру в непроизводственной среде. Поэтому мне, возможно, придется снова клонировать рабочий сервер, или есть какой-нибудь способ освободить временное пространство, которое сейчас используется?
В соответствии с вопросом @ deszo, значения переполнения памяти следующие:
Обновление 2017-06-01 18: 107 GMT
Экземпляр сервера — AWS c4.large (2 vCPU, 3,75 ГБ ОЗУ)
Источник
Ошибка Postgres SSL SYSCALL: обнаружен EOF с помощью python и psycopg
Генератор данных реального мира 1
Используя пакет psycopg2 с python 2.7, я постоянно получаю сообщение об ошибке: psycopg2.DatabaseError: SSL SYSCALL error: обнаружен EOF
Это происходит только тогда, когда я добавляю WHERE column LIKE »%X%» предложение к моему запросу pgrouting. Пример:
Обсуждения в Интернете предполагают, что это проблема с SSL интуитивно, но всякий раз, когда я комментирую сторону сопоставления с шаблоном, запрос и подключение к базе данных работают нормально.
Это в локальной базе данных под управлением Xubuntu 13.10.
После дальнейшего расследования: похоже, это может быть вызвано тем, что расширение pgrouting приводит к сбою базы данных, потому что это неправильный запрос, и это не ссылки, которые имеют этот шаблон.
Скоро отправлю ответ .
- Почему подзапрос? не имеет смысла.
- Подзапрос предназначен для функции PGR_DrivingDistance.
- 59 знаменитых последних слов: Will post an answer soon .
- Иногда ТАК делал, смеши меня: D
- 2 @PhilDonovan, не бросайте нас!
Я столкнулся с этой проблемой при выполнении медленного запроса в капле на экземпляре Digital Ocean. Все остальные SQL работали нормально, и он работал на моем ноутбуке. После масштабирования до 1 ГБ ОЗУ вместо 512 МБ он работает нормально, поэтому кажется, что эта ошибка может возникнуть, если процессу не хватает памяти.
- 2 похоже, что это не всегда исправление — я использую машину с оперативной памятью 160 ГБ и все еще имею эту ошибку при использовании pg_dump в базе данных только с SSL. используется только 15 ГБ.
- Что ж, это может сработать, но это не похоже на настоящее решение. Должен быть способ как-то это оптимизировать
- 1 Именно с чем я столкнулся! Добавил 4 ГБ пространства подкачки к экземпляру 512 МБ, и все заработало как шарм.
- У моего db выделено 16 ГБ ОЗУ, своп системы не используется, но проблема все еще возникает . Это происходит только при небольшом количестве запросов . Странно.
- @ gies0r У этой проблемы, вероятно, больше причин, чем проблем с памятью, хотя я не исключаю ее полностью.
Эта проблема возникла у меня, когда у меня выполнялись некоторые мошеннические запросы, вызывающие блокировку таблиц на неопределенный срок. Я смог увидеть запросы, запустив:
затем убейте их:
В моем случае это был убийца OOM (запрос слишком тяжелый)
- 2 Непосвященным не совсем понятно, о чем вы говорите. Пожалуйста, объясните, что dmesg есть и почему вы его запускаете.
- 1 это может быть полезно, dmesg Именно там заканчивается множество ошибок ядра Linux, обычно это сообщения драйверов (например, я много раз был в dmesg, ища, как исправить мой Wi-Fi). Когда в Linux (и ОС в целом) заканчивается память (и происходит подкачка), ядро выбирает один из текущих процессов и убивает его, чтобы освободить память. Обратите внимание, что в этот момент у ОС есть два варианта: убить один процесс или заморозить навсегда.
Вам может потребоваться выразить % в качестве %% так как % маркер-заполнитель. http://initd.org/psycopg/docs/usage.html#passing-parameters-to-sql-queries
Ошибка: psycopg2.operationalerror: SSL SYSCALL error: EOF detected
Настройка: Поток воздуха + Красное смещение + psycopg2
Когда: запросы занимают длинный время выполнения (более 300 секунд).
В этом случае происходит тайм-аут сокета. Что решает этот конкретный вариант ошибки, так это добавление аргументов поддержки активности в строку подключения.
Redshift требует keepalives_idle менее 300. У меня работало значение 30, ваш пробег может отличаться. Также возможно, что keepalives_idle аргумент — единственный, который вам нужно установить, но убедитесь, что keepalives установлен на 1.
Ссылка на документацию по сообщениям поддержки активности postgres.
Ссылка на документ по воздушному потоку, советующий по таймауту 300.
Ответ очень похож на то, что сделал @ FoxMulder900, за исключением того, что я не смог заставить его первый выбор работать. Однако это работает:
Если вы хотите убить процессы из long_running просто закомментируйте последнюю строку и вставьте SELECT pg_cancel_backend(long_running.pid) from long_running ;
Я получил эту ошибку при выполнении большого оператора UPDATE в таблице с 3 миллионами строк. В моем случае оказалось, что диск заполнен. Как только я добавил больше места, ОБНОВЛЕНИЕ работало нормально.
Источник
Ошибка SSL_read с ошибкой SSL_ERROR_SYSCALL
Мы реализовали tls с помощью openssl. При загрузке больших данных с сервера SSL_ERROR_SYSCALL возникает ошибка после получения некоторых данных. Для файлов меньшего размера я не получаю эту ошибку, могу загрузить без ошибок. ERR_get_error () показывает ноль для больших файлов.
Мы используем фреймворк linux и c ++. Как найти причину неудачи? В чем может быть причина отказа? любезно предоставьте свои предложения.
SSL_ERROR_SYSCALL указывает, что некоторая проблема произошла с базовым вводом-выводом (в данном случае это должен быть TCP). Итак, вы можете попробовать проверить с помощью errno.
Справка OpenSSL говорит:
Some I/O error occurred. The OpenSSL error queue may contain more information on the error. If the error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error: If ret == 0, an EOF was observed that violates the protocol. If ret == -1, the underlying BIO reported an I/O error (for socket I/O on Unix systems, consult errno for details).
Если вы посмотрите исходный код, SSL_get_error() вы увидите, что он возвращается SSL_ERROR_SYSCALL всякий раз, когда не уверен, что именно произошло. По сути, это код возврата по умолчанию для «неизвестного» случая.
Например, в моем случае (выполнение неблокирующего ввода-вывода с BIO):
Когда n равно 0, err будет SSL_ERROR_SYSCALL просто потому, что. Однако по- st прежнему будет 0, что указывает на отсутствие реальной ошибки. SSL_read просто вернул 0, потому что 0 байтов было записано в buf .
Однако для получения более подробной информации поищите errno / WSAGetLastError() values после звонка.
Источник
SSL_ERROR_SYSCALL typically occurs when the server side is using an SSL certificate to authenticate. This article covers how to fix SSL_ERROR_SYSCALL error in 5 ways.
SSL_ERROR_SYSCALL Error
$ git clone https://github.com/xxx/xxx.git
fatal: unable to access ‘https://github.com/xxx/xxx.git/’: LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443
Understanding SSL_ERROR_SYSCALL Error
This error typically occurs when the TCP three-way handshake between client and server completes but then a TCP reset packet (often written as “RST”) is received by the client, terminating the connection during the SSL phase.
This error is not produced when a client receives a RST packet during the three-way handshake, or after completion of the SSL/TLS negotiation (SSL phase).
Restart the computer
As we all know, restarting solves 90% of problems, and sometimes restarting the computer can directly solve the problem.
Modify Git network configuration
We can directly modify the global Git configuration file and delete the relevant configuration of HTTP / HTTPS in the file.
$ vim ~/.gitconfig
It can also be modified using the command:
- $ git config –global –unset http.proxy
- $ git config –global –unset https.proxy
Check SSL Certificate with OpenSSL
Change HTTP/HTTPS encryption library
Since the problem is that the LibreSSL library reports an error, we can modify Git to use the OpenSSL library for HTTPS communication.
$ git config –global http.sslBackend “openssl”
Use HTTPS proxy for git connection
When using HTTPS to connect to GitHub for push/pull, we need to change the local git configuration and use a proxy to initiate a request to GitHub.
Execute the following command: $ git config –global -e
This will bring us into git’s configuration file editing interface (which will open with the default editor specified by git). Add the following to this file:
[http]
proxy = socks5://127.0.0.1:7891
[https]
proxy = socks5://127.0.0.1:7891
“7891” is the designated entry and exit port of our proxy software, please modify it according to the actual situation.
Use SSH for git connection
It is well known that HTTPS or SSH can be used to clone the GitHub repository, but SSH does not have the network connection problem of HTTPS, so the connection method of push/pull can be changed from HTTPS to SSH.
Requirements: we need to generate an SSH public/private key pair in advance and add the public key to our GitHub account. See Connecting to GitHub with SSH for details on this part .
Enter the corresponding directory of the warehouse and execute the following command: $ git remote set-url origin git@github.com:xxx/xxx.git
After the change is complete, we can use the following command to view the current origin address:
$ git remote -v
Understanding X509 Certificate with Openssl Command
Содержание
- Почему возникают ошибки SSL-соединения и как их исправить?
- Что такое SSL?
- Причины возникновения ошибок SSL-соединения
- Проблемы с датой и временем
- Ненадежный SSL-сертификат
- Брандмауэр или антивирус, блокирующие сайт
- Включенный экспериментальный протокол QUIC
- Отсутствие обновлений операционной системы
- Использование SSL-сертификата версии 3.0
- Ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера
- Solve Postgres error “Error: SSL SYSCALL error: EOF detected”
- Make the queries run faster
- Adjust the connection timeout
- OpenSSL SSL_connect: SSL_ERROR_SYSCALL #9566
- Comments
- EntrepreneurAJ commented Aug 10, 2019 •
- agnosticdev commented Aug 11, 2019
- raniervf commented Aug 13, 2019
- raniervf commented Aug 13, 2019
- raniervf commented Aug 14, 2019
- raniervf commented Aug 19, 2019
- richsalz commented Aug 19, 2019
- richsalz commented Aug 19, 2019
- raniervf commented Aug 20, 2019 •
Почему возникают ошибки SSL-соединения и как их исправить?
Зачастую после установки SSL-сертификатов многие пользователи сталкиваются с ошибками, которые препятствуют корректной работе защищенного протокола HTTPS.
Предлагаем разобраться со способами устранения подобных ошибок.
Что такое SSL?
SSL (Secure Socket Layer) — это интернет-протокол для создания зашифрованного соединения между пользователем и сервером, который гарантирует безопасную передачу данных.
Когда пользователь заходит на сайт, браузер запрашивает у сервера информацию о наличии сертификата. Если сертификат установлен, сервер отвечает положительно и отправляет копию SSL-сертификата браузеру. Затем браузер проверяет сертификат, название которого должно совпадать с именем сайта, срок действия сертификата и наличие корневого сертификата, выданного центром сертификации.
Причины возникновения ошибок SSL-соединения
Когда сертификат работает корректно, адресная строка браузера выглядит примерно так:
Но при наличии ошибок она выглядит несколько иначе:
Существует множество причин возникновения таких ошибок. К числу основных можно отнести:
- Некорректную дату и время на устройстве (компьютер, смартфон, планшет и т.д.);
- Ненадежный SSL-сертификат;
- Брандмауэр или антивирус, блокирующие сайт;
- Включенный экспериментальный интернет-протокол QUIC;
- Отсутствие обновлений операционной системы;
- Использование SSL-сертификата устаревшей версии 3.0;
- Появление ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера.
Давайте рассмотрим каждую из них подробнее.
Проблемы с датой и временем
Если на устройстве установлены некорректные дата и время, ошибка SSL-соединения неизбежна, ведь при проверке сертификата происходит проверка срока его действия. Современные браузеры умеют определять такую ошибку самостоятельно и выводят сообщение о неправильно установленной дате или времени.
Для исправления этой ошибки достаточно установить на устройстве актуальное время. После этого необходимо перезагрузить страницу или браузер.
Ненадежный SSL-сертификат
Иногда при переходе на сайт, защищенный протоколом HTTPS, появляется ошибка «SSL-сертификат сайта не заслуживает доверия».
Одной из причин появления такой ошибки, как и в предыдущем случае, может стать неправильное время. Однако есть и вторая причина — браузеру не удается проверить цепочку доверия сертификата, потому что не хватает корневого сертификата. Для избавления от такой ошибки необходимо скачать специальный пакет GeoTrust Primary Certification Authority, содержащий корневые сертификаты. После скачивания переходим к установке. Для этого:
- Нажимаем сочетание клавиш Win+R и вводим команду certmgr.msc, жмем «Ок». В Windows откроется центр сертификатов.
- Раскрываем список «Доверенные корневые центры сертификации» слева, выбираем папку «Сертификаты», кликаем по ней правой кнопкой мышки и выбираем «Все задачи — импорт».
- Запустится мастер импорта сертификатов. Жмем «Далее».
- Нажимаем кнопку «Обзор» и указываем загруженный ранее сертификат. Нажимаем «Далее»:
- В следующем диалоговом окне указываем, что сертификаты необходимо поместить в доверенные корневые центры сертификации, и нажимаем «Далее». Импорт должен успешно завершиться.
После вышеперечисленных действий можно перезагрузить устройство и проверить отображение сайта в браузере.
Брандмауэр или антивирус, блокирующие сайт
Некоторые сайты блокируются брандмауэром Windows. Для проверки можно отключить брандмауэр и попробовать зайти на нужный сайт. Если SSL-сертификат начал работать корректно, значит дело в брандмауэре. В браузере Internet Explorer вы можете внести некорректно работающий сайт в список надежных и проблема исчезнет. Однако таким образом вы снизите безопасность своего устройства, так как содержимое сайта может быть небезопасным, а контроль сайта теперь отключен.
Также SSL может блокировать антивирусная программа. Попробуйте отключить в антивирусе проверку протоколов SSL и HTTPS и зайти на сайт. При необходимости добавьте сайт в список исключений антивируса.
Включенный экспериментальный протокол QUIC
QUIC — это новый экспериментальный протокол, который нужен для быстрого подключения к интернету. Основная задача протокола QUIC состоит в поддержке нескольких соединений. Вы можете отключить этот протокол в конфигурации вашего браузера.
Показываем как отключить QUIC на примере браузера Google Chrome:
- Откройте браузер и введите команду chrome://flags/#enable-quic;
- В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.
- После этого просто перезапустите браузер.
Этот способ работает и в Windows и в Mac OS.
Отсутствие обновлений операционной системы
Проблемы с SSL-сертификатами могут возникать и из-за того, что на вашей операционной системе давно не устанавливались обновлений. Особенно это касается устаревших версий Windows (7, Vista, XP и более ранние). Установите последние обновления и проверьте работу SSL.
Использование SSL-сертификата версии 3.0
Некоторые сайты используют устаревший SSL-протокол версии 3.0, который не поддерживают браузеры. По крайней мере, по умолчанию. Чтобы браузер поддерживал устаревший SSL необходимо сделать следующее (на примере браузера Google Chrome):
- Откройте браузер и перейдите в раздел «Настройки».
- Прокрутите страницу настроек вниз и нажмите «Дополнительные».
- В разделе «Система» найдите параметр «Настройки прокси-сервера» и кликните на него.
- Откроется окно. Перейдите на вкладку «Дополнительно».
- В этой вкладке вы увидите чекбокс «SSL 3.0».
- Поставьте галочку в чекбоксе, нажмите кнопку «Ок» и перезагрузите браузер.
Ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера
В процессе активации сертификата можно столкнуться с ошибкой «Invalid CSR». Такая ошибка возникает по следующим причинам:
Источник
Solve Postgres error “Error: SSL SYSCALL error: EOF detected”
I was running a scraping job from a Docker container using Python and the psycopg2 adapter that wrote the results to a Postgres database managed on DigitalOcean (DO). On random occasions, the container died, for some reason. I started debugging and these are my findings.
The error I ran into was the following:
I literally had no idea what to expect when Googling this error. Here’s what I found.
Make the queries run faster
It tends to happen with Postgres deployments that have very little RAM allocated to them. For example, I’m using the cheapest Postgres hosting on DO, it only has 512mb of memory attached to it .
In other words: the lower the memory, the longer it takes to run complex queries, with a higher probability that the connection times out.
If you can spare the bucks: add more memory.
Adjust the connection timeout
If adding more memory is not an option, try changing the keepalives parameters of your Postgres connection. For example, in psycopg2, you can do that as follows.
Let’s go over these four parameters quickly:
- keepalives (boolean): By setting this to 1, you indicate you want to use your own client-side keepalives.
- keepalives_idle (seconds): Sets the number of seconds of inactivity after which a keepalive message such be sent.
- keepalives_interval (seconds): Sets the number of seconds to wait before resending a message that has not been acknowledged by the server.
- keepalives_count (count): Sets the number of non-acknowledged keepalives to determine that the connection is dead.
So, solve the problem by making your queries run faster, or by making sure your connection doesn’t time out.
Источник
OpenSSL SSL_connect: SSL_ERROR_SYSCALL #9566
For some reason when accessing a site load balanced with GKE on Opensuse Tumbleweed the site doesn’t load I have tested this on other devices each running older versions of openssl it seems to work fine. Ironically it works without www. but adding www. it fails to load.
Running the following commands gave me the impression it is something to do with openssl
This works fine but
gives the following;
I have tested it on Android Devices, Ubuntu Devices, OpenSuse Devices, IPhones and several different online services that test a websites availability. All devices that I can get the openssl version for that work are using an earlier version of OpenSSL.
The only device that the test failed on was my OpenSuse Tumbleweed Laptop running version OpenSSL 1.1.1c 28 May 2019
I have tested if it was the browser by using chromium, chrome, chrome-unstable, firefox they all failed which made me try the curl command instead.
The text was updated successfully, but these errors were encountered:
I am able to seeing the connection setup and the body response in both requests.
I am also able to see the connection setup in the browser too with a valid response. The browsers look like they are blocking the content because it is mixed http/https. 
Hi,
I can confirme here too.
Client Win32bits with Openssl-1.1.1c, was repeatedly raising SSL_ERROR_SYSCALL with url: homologacao.sefaz.mt.gov.br
Protocol: TLS1.2
https://www.ssllabs.com/ssltest/analyze.html?d=homologacao.sefaz.mt.gov.br
Hi,
More info about SSL_ERROR_SYSCALL:
SSL Error: 0
SSL State: SSLOK
ERR: error:00000000:lib(0):func(0):reason(0)
ERR Code: 0
Its not a real bug.
homologacao.sefaz.mt.gov.br it’s closing connection, for some reason.
At first SSL_read, returns -1.
Log made with callback:
DTLS: no
protocol: TLSv1.3
cipher name: (NONE)
DTLS: no
protocol: TLSv1.3
cipher name: (NONE)
SSL_connect:before SSL initialization
DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS write client hello
DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS write client hello
DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS read server hello
DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS read server certificate
DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS read server key exchange
DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS read server done
DTLS: no
protocol: TLSv1.2
cipher name: (NONE)
SSL_connect:SSLv3/TLS write client key exchange
DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA
SSL_connect:SSLv3/TLS write change cipher spec
DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA
SSL_connect:SSLv3/TLS write finished
DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA
SSL_connect:SSLv3/TLS write finished
DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA
SSL_connect:SSLv3/TLS read change cipher spec
DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA
SSL_connect:SSLv3/TLS read finished
DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA
DTLS: no
protocol: TLSv1.2
cipher name: ECDHE-RSA-AES128-SHA
SSL Error: 5
SSL State: SSLOK
ERR: error:00000005:lib(0):func(0):DH lib
ERR Code: 0
WSAError: 10054
Hi,
I think the problem here is interoperability.
The server is Tomcat and have support only for:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Openssl-1.1.1c do not have support for CBC:
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA
The server is out of our access, then the solution is client suppport.
Howto configure openssl-1.1.1c to add CBC ciphers support?
You need to configure OpenSSL with “enable-weak-ssl-ciphers”
CBC mode is bad for HTTPS traffic, tell the server they need to upgrade. A good article on this is at https://blog.cloudflare.com/padding-oracles-and-the-decline-of-cbc-mode-ciphersuites/
Try using ALL not DEFAULT.
Openssl-11.1.c have TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 support.
But, still have interoperability problems with TomCat (homologacao.sefaz.mt.gov.br).
Attached the log build with -ssl-trace:
The the interesting part is the server dot not sent this record:
I belive thats is cause the error.
Now the question is why server is not ordering the CertificateRequest record?
Источник
Openssl-11.1.c have TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 support.
But, still have interoperability problems with TomCat (homologacao.sefaz.mt.gov.br).
Attached the log build with -ssl-trace:
The the interesting part is the server dot not sent this record:
Received Record
Header:
Version = TLS 1.2 (0x303)
Content Type = Handshake (22)
Length = 36
CertificateRequest, Length=32
certificate_types (len=3)
rsa_sign (1)
dss_sign (2)
ecdsa_sign (64)
signature_algorithms (len=24)
rsa_pkcs1_sha256 (0x0401)
dsa_sha256 (0x0402)
ecdsa_secp256r1_sha256 (0x0403)
rsa_pkcs1_sha384 (0x0501)
dsa_sha384 (0x0502)
ecdsa_secp384r1_sha384 (0x0503)
rsa_pkcs1_sha512 (0x0601)
dsa_sha512 (0x0602)
ecdsa_secp521r1_sha512 (0x0603)
rsa_pkcs1_sha1 (0x0201)
dsa_sha1 (0x0202)
ecdsa_sha1 (0x0203)
certificate_authorities (len=0)
He sents this record:
Received Record
Header:
Version = TLS 1.2 (0x303)
Content Type = Handshake (22)
Length = 4
ServerHelloDone, Length=0
I belive thats is cause the error.
Now the question is why server is not ordering the CertificateRequest record?
-----------------------------------------------------------------------------------
CONNECTED(00000798)
Sent Record
Header:
Version = TLS 1.0 (0x301)
Content Type = Handshake (22)
Length = 225
ClientHello, Length=221
client_version=0x303 (TLS 1.2)
Random:
gmt_unix_time=0x4CD41B00
random_bytes (len=28): 8C19FCA4AF5ABC5A3E12BC1F21E4E63B9103FBE1AC1CDF28E850D9DA
session_id (len=0):
cipher_suites (len=56)
{0xC0, 0x2C} TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
{0xC0, 0x30} TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
{0x00, 0x9F} TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
{0xCC, 0xA9} TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
{0xCC, 0xA8} TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
{0xCC, 0xAA} TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
{0xC0, 0x2B} TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
{0xC0, 0x2F} TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
{0x00, 0x9E} TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
{0xC0, 0x24} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
{0xC0, 0x28} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
{0x00, 0x6B} TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
{0xC0, 0x23} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
{0xC0, 0x27} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
{0x00, 0x67} TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
{0xC0, 0x0A} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
{0xC0, 0x14} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
{0x00, 0x39} TLS_DHE_RSA_WITH_AES_256_CBC_SHA
{0xC0, 0x09} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
{0xC0, 0x13} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
{0x00, 0x33} TLS_DHE_RSA_WITH_AES_128_CBC_SHA
{0x00, 0x9D} TLS_RSA_WITH_AES_256_GCM_SHA384
{0x00, 0x9C} TLS_RSA_WITH_AES_128_GCM_SHA256
{0x00, 0x3D} TLS_RSA_WITH_AES_256_CBC_SHA256
{0x00, 0x3C} TLS_RSA_WITH_AES_128_CBC_SHA256
{0x00, 0x35} TLS_RSA_WITH_AES_256_CBC_SHA
{0x00, 0x2F} TLS_RSA_WITH_AES_128_CBC_SHA
{0x00, 0xFF} TLS_EMPTY_RENEGOTIATION_INFO_SCSV
compression_methods (len=1)
No Compression (0x00)
extensions, length = 124
extension_type=server_name(0), length=32
0000 - 00 1e 00 00 1b 68 6f 6d-6f 6c 6f 67 61 63 61 .....homologaca
000f - 6f 2e 73 65 66 61 7a 2e-6d 74 2e 67 6f 76 2e o.sefaz.mt.gov.
001e - 62 72 br
extension_type=ec_point_formats(11), length=4
uncompressed (0)
ansiX962_compressed_prime (1)
ansiX962_compressed_char2 (2)
extension_type=supported_groups(10), length=12
ecdh_x25519 (29)
secp256r1 (P-256) (23)
ecdh_x448 (30)
secp521r1 (P-521) (25)
secp384r1 (P-384) (24)
extension_type=session_ticket(35), length=0
extension_type=encrypt_then_mac(22), length=0
extension_type=extended_master_secret(23), length=0
extension_type=signature_algorithms(13), length=48
ecdsa_secp256r1_sha256 (0x0403)
ecdsa_secp384r1_sha384 (0x0503)
ecdsa_secp521r1_sha512 (0x0603)
ed25519 (0x0807)
ed448 (0x0808)
rsa_pss_pss_sha256 (0x0809)
rsa_pss_pss_sha384 (0x080a)
rsa_pss_pss_sha512 (0x080b)
rsa_pss_rsae_sha256 (0x0804)
rsa_pss_rsae_sha384 (0x0805)
rsa_pss_rsae_sha512 (0x0806)
rsa_pkcs1_sha256 (0x0401)
rsa_pkcs1_sha384 (0x0501)
rsa_pkcs1_sha512 (0x0601)
ecdsa_sha224 (0x0303)
ecdsa_sha1 (0x0203)
rsa_pkcs1_sha224 (0x0301)
rsa_pkcs1_sha1 (0x0201)
dsa_sha224 (0x0302)
dsa_sha1 (0x0202)
dsa_sha256 (0x0402)
dsa_sha384 (0x0502)
dsa_sha512 (0x0602)
Received Record
Header:
Version = TLS 1.2 (0x303)
Content Type = Handshake (22)
Length = 95
ServerHello, Length=91
server_version=0x303 (TLS 1.2)
Random:
gmt_unix_time=0x5D2695FE
random_bytes (len=28): 11250502DB25FAE8E20B480E4D5EAD49E35681BD23390EF7B872805A
session_id (len=32): D208D422264D4807BBD098018C95F08F0A713226B30B5303FE9717665E25409F
cipher_suite {0xC0, 0x13} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
compression_method: No Compression (0x00)
extensions, length = 19
extension_type=renegotiate(65281), length=1
<EMPTY>
extension_type=server_name(0), length=0
extension_type=ec_point_formats(11), length=2
uncompressed (0)
extension_type=extended_master_secret(23), length=0
Received Record
Header:
Version = TLS 1.2 (0x303)
Content Type = Handshake (22)
Length = 2816
Certificate, Length=2812
certificate_list, length=2809
ASN.1Cert, length=1629
------details-----
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:85:45:46:11:10:a6:1e:54:31:48:31:62:52:64:7e:5b:72
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Validity
Not Before: Jul 31 13:04:24 2019 GMT
Not After : Oct 29 13:04:24 2019 GMT
Subject: CN = *.sefaz.mt.gov.br
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
00:d9:95:a3:f5:48:79:04:b7:0a:d3:a2:47:0b:ab:
ac:70:f7:3d:b5:d0:00:33:99:53:21:5c:20:c1:eb:
3e:d5:6b:48:ec:6a:2a:dd:d5:3a:4b:52:d5:e3:64:
8f:c1:50:63:2f:64:78:7d:77:d6:1d:06:56:80:93:
1a:6b:cd:e7:52:5a:35:e1:3b:86:d4:12:82:1e:f0:
66:8a:bd:26:e3:87:0a:71:21:b2:64:55:15:f3:19:
1c:03:a6:53:bb:c3:cd:a1:6d:73:09:4a:58:57:6c:
f7:92:b2:8d:c6:a1:05:42:17:08:45:2b:2f:80:8e:
78:9d:e3:2f:76:45:72:24:50:2a:83:f0:5b:64:9b:
4e:ab:ef:60:d8:d2:9b:81:f9:7f:ef:7d:a8:49:0c:
74:5d:a4:6f:bf:23:57:5a:02:1f:1c:21:8c:52:bb:
e8:84:e4:86:38:93:a3:f1:14:c8:0f:ba:0d:b8:6e:
48:49:ec:8b:de:3a:f6:11:fd:b3:e3:4f:87:ba:ac:
48:d4:c0:b5:25:f5:ca:e1:99:94:8f:a3:23:ba:6a:
a3:f5:0d:6c:ee:32:d5:bf:42:f8:6f:62:12:80:e7:
99:1c:3d:23:7c:18:a3:ab:23:2b:94:db:c0:89:fb:
65:e8:fc:e5:9a:92:4c:37:9c:ee:99:2f:e1:4e:d2:
2d:b0:bc:62:04:41:0b:f9:6b:2f:54:10:e9:c9:cf:
54:cc:15:69:8f:15:28:12:d7:62:29:16:b6:87:cd:
a4:48:cf:2c:d9:3b:71:2c:9d:9a:7d:40:c8:5d:d5:
99:3a:c6:31:5f:01:bb:ac:e0:a9:b7:44:23:49:7e:
2f:27:30:18:21:8e:f8:44:73:b1:6a:58:e8:88:55:
3e:6e:08:47:5d:23:0d:65:45:d8:38:5c:88:31:2a:
ca:0a:1e:f7:b2:39:06:08:6e:a2:39:4b:90:cb:6b:
ce:5d:21:ff:e7:da:43:da:cc:f8:0c:c8:1d:82:6b:
b2:36:76:e2:a1:72:20:1d:57:8f:41:f2:88:0d:9d:
92:79:a6:2f:0c:77:33:aa:30:9e:58:39:15:25:ba:
65:eb:e9:40:04:6d:29:24:ad:18:40:8d:0a:88:ca:
78:92:fd:85:a0:76:3c:f5:3d:1a:d4:24:77:6f:fa:
71:03:6c:04:bc:86:7e:96:53:bf:3d:ad:0b:e8:b6:
37:3d:9d:d2:99:77:24:84:01:b7:e6:97:08:d7:34:
29:2e:85:3b:47:a4:fc:d8:83:29:ce:05:4d:8a:db:
17:30:ff:90:2d:eb:08:e0:2a:79:7d:d6:37:1a:08:
a7:5f:0b:94:74:77:3a:dc:9d:91:d6:b6:b5:ae:c5:
9c:15:15
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
19:42:7E:8C:A9:A8:8E:8E:EB:D1:7A:83:51:E2:9D:62:D4:D2:2D:C8
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:*.sefaz.mt.gov.br
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 74:7E:DA:83:31:AD:33:10:91:21:9C:CE:25:4F:42:70:
C2:BF:FD:5E:42:20:08:C6:37:35:79:E6:10:7B:CC:56
Timestamp : Jul 31 14:04:24.522 2019 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:44:02:20:0F:0F:9A:74:E9:B2:DC:BA:F0:BB:D4:66:
43:3B:7A:99:4E:99:9B:52:8A:12:71:BA:65:37:D8:EE:
1C:93:71:B9:02:20:41:30:E0:D6:14:E6:94:83:68:69:
0B:5B:25:C0:75:71:27:84:16:0C:61:F5:6C:17:F4:1A:
34:C0:F7:C0:18:00
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 29:3C:51:96:54:C8:39:65:BA:AA:50:FC:58:07:D4:B7:
6F:BF:58:7A:29:72:DC:A4:C3:0C:F4:E5:45:47:F4:78
Timestamp : Jul 31 14:04:24.569 2019 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:52:52:D5:86:CB:72:7F:FA:D7:60:9C:08:
F1:77:EC:AB:A1:09:DE:EB:30:B9:53:24:AF:05:D4:BC:
B7:C5:7F:68:02:21:00:EF:6C:86:4C:A7:1B:FB:7B:7E:
BD:50:EF:6C:C6:35:9D:40:1E:C6:AF:6B:AA:37:CA:2F:
25:F4:49:41:A3:4F:71
Signature Algorithm: sha256WithRSAEncryption
5a:c0:33:7d:c0:37:53:ce:14:e7:b8:f1:6c:65:0c:a8:49:d2:
f0:2a:ca:d4:f0:a4:5e:27:88:30:30:ce:4f:8e:df:fc:f8:67:
86:be:da:45:c8:48:e5:5a:eb:cc:eb:66:08:09:d8:2c:52:a1:
28:f7:1d:55:99:94:8e:0a:ce:a8:62:75:2b:8b:ba:11:8c:d5:
8d:fb:34:b5:cf:3e:e1:40:33:3e:ae:50:30:f9:d4:60:d0:07:
7f:76:ef:b2:85:2a:58:57:37:35:23:1f:aa:55:73:f2:a5:40:
9f:74:d1:e0:6e:66:fe:a4:4d:3a:47:4b:33:48:a1:f1:49:c1:
af:61:ab:c2:74:e4:1c:63:f5:df:e2:0d:a9:58:bf:c3:c2:0a:
0b:cf:c6:23:be:82:c2:60:8c:32:81:eb:c7:fa:fa:71:93:4e:
3f:d6:ea:51:ce:8b:5e:ca:4c:8b:f0:48:28:9f:a0:52:f2:d1:
34:ed:aa:3e:ae:22:0a:e9:57:0a:4b:47:49:b4:d0:52:44:32:
1d:5e:30:ec:44:d0:a6:fc:0e:fa:4a:31:b0:bd:c2:aa:d5:38:
e3:1c:7b:88:d8:e8:8b:4d:e1:9a:b8:1f:b9:af:e1:be:47:42:
fc:91:49:ef:a2:6e:c5:78:cd:31:74:30:53:b2:ce:7e:59:ad:
bb:ec:9a:de
-----BEGIN CERTIFICATE-----
MIIGWTCCBUGgAwIBAgISA4VFRhEQph5UMUgxYlJkfltyMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTA3MzExMzA0MjRaFw0x
OTEwMjkxMzA0MjRaMBwxGjAYBgNVBAMMESouc2VmYXoubXQuZ292LmJyMIICIjAN
BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2ZWj9Uh5BLcK06JHC6uscPc9tdAA
M5lTIVwgwes+1WtI7Goq3dU6S1LV42SPwVBjL2R4fXfWHQZWgJMaa83nUlo14TuG
1BKCHvBmir0m44cKcSGyZFUV8xkcA6ZTu8PNoW1zCUpYV2z3krKNxqEFQhcIRSsv
gI54neMvdkVyJFAqg/BbZJtOq+9g2NKbgfl/732oSQx0XaRvvyNXWgIfHCGMUrvo
hOSGOJOj8RTID7oNuG5ISeyL3jr2Ef2z40+HuqxI1MC1JfXK4ZmUj6Mjumqj9Q1s
7jLVv0L4b2ISgOeZHD0jfBijqyMrlNvAiftl6PzlmpJMN5zumS/hTtItsLxiBEEL
+WsvVBDpyc9UzBVpjxUoEtdiKRa2h82kSM8s2TtxLJ2afUDIXdWZOsYxXwG7rOCp
t0QjSX4vJzAYIY74RHOxaljoiFU+bghHXSMNZUXYOFyIMSrKCh73sjkGCG6iOUuQ
y2vOXSH/59pD2sz4DMgdgmuyNnbioXIgHVePQfKIDZ2SeaYvDHczqjCeWDkVJbpl
6+lABG0pJK0YQI0KiMp4kv2FoHY89T0a1CR3b/pxA2wEvIZ+llO/Pa0L6LY3PZ3S
mXckhAG35pcI1zQpLoU7R6T82IMpzgVNitsXMP+QLesI4Cp5fdY3GginXwuUdHc6
3J2R1ra1rsWcFRUCAwEAAaOCAmUwggJhMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE
FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU
GUJ+jKmojo7r0XqDUeKdYtTSLcgwHwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl
7/Oo7KEwbwYIKwYBBQUHAQEEYzBhMC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcC5p
bnQteDMubGV0c2VuY3J5cHQub3JnMC8GCCsGAQUFBzAChiNodHRwOi8vY2VydC5p
bnQteDMubGV0c2VuY3J5cHQub3JnLzAcBgNVHREEFTATghEqLnNlZmF6Lm10Lmdv
di5icjBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsG
AQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQMGCisGAQQB1nkC
BAIEgfQEgfEA7wB1AHR+2oMxrTMQkSGcziVPQnDCv/1eQiAIxjc1eeYQe8xWAAAB
bEhYpEoAAAQDAEYwRAIgDw+adOmy3Lrwu9RmQzt6mU6Zm1KKEnG6ZTfY7hyTcbkC
IEEw4NYU5pSDaGkLWyXAdXEnhBYMYfVsF/QaNMD3wBgAAHYAKTxRllTIOWW6qlD8
WAfUt2+/WHopctykwwz05UVH9HgAAAFsSFikeQAABAMARzBFAiBSUtWGy3J/+tdg
nAjxd+yroQne6zC5UySvBdS8t8V/aAIhAO9shkynG/t7fr1Q72zGNZ1AHsava6o3
yi8l9ElBo09xMA0GCSqGSIb3DQEBCwUAA4IBAQBawDN9wDdTzhTnuPFsZQyoSdLw
KsrU8KReJ4gwMM5Pjt/8+GeGvtpFyEjlWuvM62YICdgsUqEo9x1VmZSOCs6oYnUr
i7oRjNWN+zS1zz7hQDM+rlAw+dRg0Ad/du+yhSpYVzc1Ix+qVXPypUCfdNHgbmb+
pE06R0szSKHxScGvYavCdOQcY/Xf4g2pWL/DwgoLz8YjvoLCYIwygevH+vpxk04/
1upRzoteykyL8Egon6BS8tE07ao+riIK6VcKS0dJtNBSRDIdXjDsRNCm/A76SjGw
vcKq1TjjHHuI2OiLTeGauB+5r+G+R0L8kUnvom7FeM0xdDBTss5+Wa277Jre
-----END CERTIFICATE-----
------------------
extensions, length = 4
extensions, extype = 38448, extlen = 33284
0000 - 96 30 82 04 .0..
Message length parse error!
Received Record
Header:
Version = TLS 1.2 (0x303)
Content Type = Handshake (22)
Length = 589
ServerKeyExchange, Length=585
KeyExchangeAlgorithm=ECDHE
named_curve: secp256r1 (P-256) (23)
point (len=65): 0423B2D4441B9AE65E5B3F885C80E63AC87F3F162C168CC0B99DC3ECDA184838A4A6CAC65CD3A10185101590EE4328B09C6B8BB5537DFA077C7926DFF9F673C12A
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature (len=512): 24B6E1D604A150B1B977854AA5C0883DCA5D8BA51DAC648C7789FA67FB69F23064F71B111315EAC61CCCB41ECD8DF4670AD45C309CB74F01191246A42C0228E42E974950F7630889430F9B6E45AC787BB20168712B9343C6EA573944C4E5852C83C6C24E03673F5467242FB654F1D9D2FE33413E1AB50D7E5EB93C764DD7CC81E2026C5BCCE983F192969CCDFDDDEC7EDE48702FEF54A889FE48132FF0F339BFDC84304F0A19C6669C59EAAE45351B02833B24DAD75E3BBAAB6471EAAD1D13B21F59CAC74DE097F6037EE6646781F79EEFC44EA742385AE6C9CA3BF8ACEBFB4B11ED5007E032616C5DFB3330F6EB3F770947804D29782846BDD4B53F0B8EB8EEB2F6D5E42A1B240E63733F79004CE64B72DBD867ACBEEC51421B210CB667D2F71D75A96679380DE4005F027BBD3C8C5BA21A0C6DF4F504A40DA9B6B41FB74FCE5A1F2D34466A01BBAF72696BB13AE9863076B4776A08EDD4F415C827EC1B0D4DFFBB0E5A2DB5C587440A0F3554300B041D6B1B24AFE07D9F4F5E2D8D6DC7E6370F50B16D6E0093C5018484BB49B7F65B4CED9E07006F390AC1719B00C027B0154FBAF799B761CE43CA4C9C92E8C348CD1403F005A9B2DE284950C76CFFE2FFEDDC763DB74AE279E77AC80E13157401A6475012C4C4BA252CD126966B5F084A50045DBC47D741BF0D942FDA391DE39E0770F0FED771FA5A191C92138E9CBE36A8
Received Record
Header:
Version = TLS 1.2 (0x303)
Content Type = Handshake (22)
Length = 4
ServerHelloDone, Length=0
Sent Record
Header:
Version = TLS 1.2 (0x303)
Content Type = Handshake (22)
Length = 70
ClientKeyExchange, Length=66
KeyExchangeAlgorithm=ECDHE
ecdh_Yc (len=65): 04A2C8F7CB0383A48DEE27AF79D9D210D4A346FAA44784604A11D003CC6488C547C693CEF141AED0535E0ECF67B3974CCCA85D3251C7E64B5FF1CBD4F68F963BAD
Sent Record
Header:
Version = TLS 1.2 (0x303)
Content Type = ChangeCipherSpec (20)
Length = 1
change_cipher_spec (1)
Sent Record
Header:
Version = TLS 1.2 (0x303)
Content Type = Handshake (22)
Length = 64
Finished, Length=12
verify_data (len=12): 063BF14FCCDDC30F56E193C3
Received Record
Header:
Version = TLS 1.2 (0x303)
Content Type = ChangeCipherSpec (20)
Length = 1
Received Record
Header:
Version = TLS 1.2 (0x303)
Content Type = Handshake (22)
Length = 64
Finished, Length=12
verify_data (len=12): CEE155B9EEBB61BE4BE37AD6
---
Certificate chain
0 s:CN = *.sefaz.mt.gov.br
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGWTCCBUGgAwIBAgISA4VFRhEQph5UMUgxYlJkfltyMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTA3MzExMzA0MjRaFw0x
OTEwMjkxMzA0MjRaMBwxGjAYBgNVBAMMESouc2VmYXoubXQuZ292LmJyMIICIjAN
BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2ZWj9Uh5BLcK06JHC6uscPc9tdAA
M5lTIVwgwes+1WtI7Goq3dU6S1LV42SPwVBjL2R4fXfWHQZWgJMaa83nUlo14TuG
1BKCHvBmir0m44cKcSGyZFUV8xkcA6ZTu8PNoW1zCUpYV2z3krKNxqEFQhcIRSsv
gI54neMvdkVyJFAqg/BbZJtOq+9g2NKbgfl/732oSQx0XaRvvyNXWgIfHCGMUrvo
hOSGOJOj8RTID7oNuG5ISeyL3jr2Ef2z40+HuqxI1MC1JfXK4ZmUj6Mjumqj9Q1s
7jLVv0L4b2ISgOeZHD0jfBijqyMrlNvAiftl6PzlmpJMN5zumS/hTtItsLxiBEEL
+WsvVBDpyc9UzBVpjxUoEtdiKRa2h82kSM8s2TtxLJ2afUDIXdWZOsYxXwG7rOCp
t0QjSX4vJzAYIY74RHOxaljoiFU+bghHXSMNZUXYOFyIMSrKCh73sjkGCG6iOUuQ
y2vOXSH/59pD2sz4DMgdgmuyNnbioXIgHVePQfKIDZ2SeaYvDHczqjCeWDkVJbpl
6+lABG0pJK0YQI0KiMp4kv2FoHY89T0a1CR3b/pxA2wEvIZ+llO/Pa0L6LY3PZ3S
mXckhAG35pcI1zQpLoU7R6T82IMpzgVNitsXMP+QLesI4Cp5fdY3GginXwuUdHc6
3J2R1ra1rsWcFRUCAwEAAaOCAmUwggJhMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE
FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU
GUJ+jKmojo7r0XqDUeKdYtTSLcgwHwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl
7/Oo7KEwbwYIKwYBBQUHAQEEYzBhMC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcC5p
bnQteDMubGV0c2VuY3J5cHQub3JnMC8GCCsGAQUFBzAChiNodHRwOi8vY2VydC5p
bnQteDMubGV0c2VuY3J5cHQub3JnLzAcBgNVHREEFTATghEqLnNlZmF6Lm10Lmdv
di5icjBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsG
AQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQMGCisGAQQB1nkC
BAIEgfQEgfEA7wB1AHR+2oMxrTMQkSGcziVPQnDCv/1eQiAIxjc1eeYQe8xWAAAB
bEhYpEoAAAQDAEYwRAIgDw+adOmy3Lrwu9RmQzt6mU6Zm1KKEnG6ZTfY7hyTcbkC
IEEw4NYU5pSDaGkLWyXAdXEnhBYMYfVsF/QaNMD3wBgAAHYAKTxRllTIOWW6qlD8
WAfUt2+/WHopctykwwz05UVH9HgAAAFsSFikeQAABAMARzBFAiBSUtWGy3J/+tdg
nAjxd+yroQne6zC5UySvBdS8t8V/aAIhAO9shkynG/t7fr1Q72zGNZ1AHsava6o3
yi8l9ElBo09xMA0GCSqGSIb3DQEBCwUAA4IBAQBawDN9wDdTzhTnuPFsZQyoSdLw
KsrU8KReJ4gwMM5Pjt/8+GeGvtpFyEjlWuvM62YICdgsUqEo9x1VmZSOCs6oYnUr
i7oRjNWN+zS1zz7hQDM+rlAw+dRg0Ad/du+yhSpYVzc1Ix+qVXPypUCfdNHgbmb+
pE06R0szSKHxScGvYavCdOQcY/Xf4g2pWL/DwgoLz8YjvoLCYIwygevH+vpxk04/
1upRzoteykyL8Egon6BS8tE07ao+riIK6VcKS0dJtNBSRDIdXjDsRNCm/A76SjGw
vcKq1TjjHHuI2OiLTeGauB+5r+G+R0L8kUnvom7FeM0xdDBTss5+Wa277Jre
-----END CERTIFICATE-----
subject=CN = *.sefaz.mt.gov.br
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3599 bytes and written 380 bytes
Verification: OK
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-SHA
Session-ID: D208D422264D4807BBD098018C95F08F0A713226B30B5303FE9717665E25409F
Session-ID-ctx:
Master-Key: 167506D4C95703376589FF931D839A143381E2DFCCC8BC27D069F23310E337E4097BA15CB9277D6D44B70AEBFFBCA679
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1566304360
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
I was running a scraping job from a Docker container using Python and the psycopg2 adapter that wrote the results to a Postgres database managed on DigitalOcean (DO). On random occasions, the container died, for some reason. I started debugging and these are my findings.
The error I ran into was the following:
Error: SSL SYSCALL error: EOF detectedI literally had no idea what to expect when Googling this error. Here’s what I found.
Make the queries run faster
It tends to happen with Postgres deployments that have very little RAM allocated to them. For example, I’m using the cheapest Postgres hosting on DO, it only has 512mb of memory attached to it .
In other words: the lower the memory, the longer it takes to run complex queries, with a higher probability that the connection times out.
If you can spare the bucks: add more memory.
Adjust the connection timeout
If adding more memory is not an option, try changing the keepalives parameters of your Postgres connection. For example, in psycopg2, you can do that as follows.
keepalive_kwargs = {
"keepalives": 1,
"keepalives_idle": 60,
"keepalives_interval": 10,
"keepalives_count": 5
}
conn = psycopg2.connect(
host = 'YOUR_HOST>',
database = '<DB_NAME>',
user = '<USER>',
password = '<PASSWORD>',
port = 25060,
**keepalive_kwargs
)
Let’s go over these four parameters quickly:
- keepalives (boolean): By setting this to 1, you indicate you want to use your own client-side keepalives.
- keepalives_idle (seconds): Sets the number of seconds of inactivity after which a keepalive message such be sent.
- keepalives_interval (seconds): Sets the number of seconds to wait before resending a message that has not been acknowledged by the server.
- keepalives_count (count): Sets the number of non-acknowledged keepalives to determine that the connection is dead.
So, solve the problem by making your queries run faster, or by making sure your connection doesn’t time out.
Great success!