Неопределенная ошибка x509 certificate type signature fail

As the various other answers to this question show, there are many different possible causes for this error message. The reason why it is happening to you may be totally different from the reasons why it is happening to me. And unfortunately, the error message is completely failing to point at the actual source of the problem, so it is completely unhelpful in troubleshooting. It is in fact entirely misleading.

So, instead of giving you yet one more from the myriad of possible causes of this error message, what I will do instead is show you how to troubleshoot this problem so as to find out what is causing it in your particular situation.

At work we commonly use the following two commands to enable some software to talk to various servers, for example to enable IntelliJ IDEA to talk to our internal maven repositories:

[Elevated]keytool 
    -printcert -rfc -sslserver maven.services.{our-company}.com:443 > public.crt

[Elevated]keytool
    -import -storepass changeit -noprompt -trustcacerts -alias services.{our-company}.com 
    -keystore libsecuritycacerts -file public.crt

Now, what sometimes happens is that the keytool -printcert command is unable to do its job, either due to misconfiguration, or simply because of temporary connectivity issues, such as the firewall preventing it, the user forgot to start his VPN, whatever. It is a fact of life that this may happen. This is not actually the problem.

The problem is that when the stupid tool encounters such an error, it does not emit the error message to the standard error device, it emits it to the standard output device!

So here is what ends up happening:

• When you execute the first command, you don’t see any error message, so you have no idea that it failed. However, instead of a key, the public.crt file now contains an error message saying keytool error: java.lang.Exception: No certificate from the SSL server.
• When you execute the second command, it reads public.crt and it finds the text of the error message instead of a key in it, so it fails, saying keytool error: java.lang.Exception: Input not an X.509 certificate.

Bottom line is: after keytool -printcert ... > public.crt always dump the contents of public.crt to make sure it is actually a key and not an error message before proceeding to run keytool -import ... -file public.crt

Настройка SSL с IIS

Я пытаюсь обновить сертификат SSL в соответствии с этим сообщением.

Я новичок в сертификатах, поэтому я последовал этому руководству. Но когда я вхожу

keytool -keystore mycacerts -storepass changeit -importcert -file 'C:UsersNoksDesktopcacerts.pem' -v 

Я получаю сообщение об ошибке:

keytool error: java.lang.Exception: Input not an X.509 certificate java.lang.Exception: Input not an X.509 certificate at sun.security.tools.KeyTool.addTrustedCert(KeyTool.java:1913) at sun.security.tools.KeyTool.doCommands(KeyTool.java:818) at sun.security.tools.KeyTool.run(KeyTool.java:172) at sun.security.tools.KeyTool.main(KeyTool.java:166) 

Как это исправить?

• Я думаю, что эта команда отлично работает в java 1.6 или выше

Содержит ли ваш файл cacerts.pem единый сертификат? Поскольку это PEM, взгляните на него (с помощью текстового редактора), он должен начинаться с

-----BEGIN CERTIFICATE-----

и закончить

-----END CERTIFICATE-----

Наконец, чтобы убедиться, что он не поврежден, возьмите openssl и распечатайте его данные, используя

openssl x509 -in cacerts.pem -text

• Ну, у него было много таких модулей, я просто модифицировал его, включив один, он успешно установлен. 🙂
• 1 Вы только что добавили BEGIN CERTIFICATE и END CERTIFICATE между всеми данными? Я тоже столкнулся с той же проблемой, не могли бы вы помочь мне, сказав то, что вы сделали?
• 2 Строки уже должны быть там. Если это не так, вероятно, ваш сертификат закодирован в формате DER (или недействителен). Чтобы преобразовать это сделать openssl x509 -in mycert.der -inform DER -out myCert.pem -outform PEM. Для просмотра и проверки openssl -in myCert.pem -text. Файл должен содержать единственный сертификат.
• 11 Проблема также может заключаться в том, что keytool может быть немного чрезмерно чувствительным к пробелам и окончанию строки. Я пытался импортировать Давайте зашифровать сертификат, и это не удалось из-за этого, и я исправил формат сертификата с помощью openssl x509 -in broken.pem -out correct.pem и он импортировал correct.pem без проблем.
• нижний регистр x509 важен!

Многие центры сертификации предоставляют сертификат в формате PKCS7.

Согласно документации Oracle, команда keytool может обрабатывать PKCS # 7, но иногда не работает

Команда keytool может импортировать сертификаты X.509 v1, v2 и v3, а также цепочки сертификатов в формате PKCS # 7, состоящие из сертификатов этого типа. Импортируемые данные должны быть предоставлены либо в формате двоичного кодирования, либо в формате кодирования для печати (также известном как кодирование Base64), как определено в стандарте Internet RFC 1421. В последнем случае кодировка должна быть ограничена в начале строкой, которая начинается с —— BEGIN, и ограничена в конце строкой, которая начинается с —— END.

Если файл PKCS7 не может быть импортирован, попробуйте преобразовать его из PKCS7 в X.509:

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer 

• 1 Документ не разъясняет, что когда вы -importcert к существующей записи частного ключа он ожидает «ответ сертификата», который может быть либо отдельным сертификатом, либо цепочкой, включающей PKCS7 с использованием CertificateFactory.generateCertificates (с s в конце), но когда вы -importcert для новой записи доверенного сертификата он ожидает только один сертификат, а НЕ PKCS7, используя generateCertificate (нет). Если вы хотите доверять нескольким сертификатам в цепочке (а суть цепочки в том, что в этом нет необходимости), вы должны импортировать их по отдельности в разные псевдонимы.

Это похоже на старый тред, но я добавлю сюда свой опыт. Я тоже попытался установить сертификат и получил эту ошибку. Затем я открыл файл cer с помощью текстового редактора и заметил, что в конце каждой строки есть лишний пробел (символ). Удаление этих строк позволило мне импортировать сертификат.

Надеюсь, это чего-то стоит для кого-то другого.

• Это было проблемой и для меня, я думаю, потому что я скопировал текст сертификата прямо из электронного письма от поставщика сертификата, он оставил пробел в конце каждой строки.
• Иисус Христос. Это действительно спасло меня. Спасибо!

Я также добавлю сюда свой опыт, если он кому-то поможет:

На работе мы обычно используем следующие две команды, чтобы позволить IntelliJ IDEA взаимодействовать с различными серверами, например с нашими внутренними репозиториями maven:

[Elevated]C:Program FilesJetBrainsIntelliJ IDEA {version}jre64>binkeytool -printcert -rfc -sslserver maven.services.{our-company}.com:443 > public.crt [Elevated]C:Program FilesJetBrainsIntelliJ IDEA {version}jre64>binkeytool -import -storepass changeit -noprompt -trustcacerts -alias services.{our-company}.com -keystore libsecuritycacerts -file public.crt 

Иногда случается, что keytool -printcert команда не может связаться с внешним миром из-за временных проблем с подключением, таких как брандмауэр, препятствующий этому, пользователь забыл запустить свой VPN и т. д. Это факт жизни, что это может случиться. На самом деле проблема не в этом.

Проблема в том, что когда глупый инструмент обнаруживает такую ​​ошибку, он не выдает сообщение об ошибке на стандартное устройство ошибки, а выдает его на стандартное устройство вывода!

Итак, вот что в итоге происходит:

• Когда вы выполняете первую команду, вы не видите сообщения об ошибке, поэтому вы не знаете, что это не удалось. Однако вместо ключа public.crt файл теперь содержит сообщение об ошибке keytool error: java.lang.Exception: No certificate from the SSL server.
• Когда вы выполняете вторую команду, она находит сообщение об ошибке вместо ключа в public.crt, поэтому он терпит неудачу, говоря keytool error: java.lang.Exception: Input not an X.509 certificate.

Итог: после keytool -printcert ... > public.crt всегда выгружать содержимое public.crt чтобы убедиться, что это действительно ключ, а не сообщение об ошибке, прежде чем продолжить keytool -import ... -file public.crt

Я изменил 3 вещи, и теперь все работает:

1. Есть столбик пробелов, я их убрал
2. Изменен разрыв строки с Windows CRLF на linux LF
3. Убрана пустая строка в конце.

AlexanderOT1	#1 Оставлено : 10 июля 2020 г. 9:27:53(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 05.06.2020(UTC) Сообщений: 25 Сказал(а) «Спасибо»: 3 раз	Есть тестовый сервер Криптопро http://testgost2012.cryptopro.ru/certsrv/ http://testgost2012.cryp….ru/certsrv/certcarc.asp Написано Чтобы доверять сертификатам, выданным этим центром сертификации, установите эту цепочку сертификатов ЦС. Пробую импортировать в jcp-2.0.40502, Java7, Linux в cacerts JCP установлено в Java командой setup_console, ошибок не было при установке. /opt/java64/1.7.0_72/jre/bin/keytool -importcert -file «./certnew.cer» -alias CryptoPro_CA -keystore «/opt/java64/1.7.0_72/jre/lib/security/cacerts» -storepass changeit или так /opt/java64/1.7.0_72/jre/bin/keytool -J-Dkeytool.compat=true -J-Duse.cert.stub=true -provider ru.CryptoPro.JCP.JCP -importcert -file «./certnew.cer» -alias CryptoPro_CA -keystore «/opt/java64/1.7.0_72/jre/lib/security/cacerts» -storepass changeit В обоих случаях выдается ошибка keytool error: java.lang.Exception: Input not an X.509 certificate Пробовал оба варианта: Загрузка сертификата ЦС Загрузка цепочки сертификатов ЦС Пробовал импортировать сертификат ЦС в Windows, экспортировать его в DER Encoded Binary X.509 (.CER) Во всех вариантах одна и та же ошибка на Linux

AlexanderOT1	#2 Оставлено : 10 июля 2020 г. 9:42:55(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 05.06.2020(UTC) Сообщений: 25 Сказал(а) «Спасибо»: 3 раз	Команда C:Javajdk1.7.0_79jrebinkeytool -importcert -file «certnew.cer» -alias CryptoPro_CA -keystore «C:Javajdk1.7.0_79jrelibsecuritycacerts» -storepass changeit На Windows сработала без ошибок

AlexanderOT1	#3 Оставлено : 10 июля 2020 г. 12:50:11(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 05.06.2020(UTC) Сообщений: 25 Сказал(а) «Спасибо»: 3 раз	Скопировал cacerts из Java (Windows) в Java (Linux). При попытке получить информацию о сертификате из cacerts он его находит, но выдает ошибку. /opt/java64/1.7.0_72/jre/bin/keytool -list -v -keystore «/opt/java64/1.7.0_72/jre/lib/security/cacerts» -alias CryptoPro_CA keytool error: java.security.cert.CertificateException: Certificate contains invalid public key: Unrecognized public key. java.security.cert.CertificateException: Certificate contains invalid public key: Unrecognized public key. at com.rsa.cryptoj.o.pk.g(Unknown Source) at com.rsa.cryptoj.o.pk.<init>(Unknown Source) at com.rsa.cryptoj.o.pj.<init>(Unknown Source) at com.rsa.cryptoj.o.pg.a(Unknown Source) at com.rsa.cryptoj.o.ot.engineGenerateCertificate(Unknown Source) at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:339) at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:747) at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55) at java.security.KeyStore.load(KeyStore.java:1214) at sun.security.tools.KeyTool.doCommands(KeyTool.java:789) at sun.security.tools.KeyTool.run(KeyTool.java:340) at sun.security.tools.KeyTool.main(KeyTool.java:333)

Евгений Афанасьев	#4 Оставлено : 10 июля 2020 г. 15:57:25(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,740 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 647 раз в 610 постах	Здравствуйте. 1. Команда: Код: /opt/java64/1.7.0_72/jre/bin/keytool -J-Dkeytool.compat=true -J-Duse.cert.stub=true -provider ru.CryptoPro.JCP.JCP -importcert -file "./certnew.cer" -alias CryptoPro_CA -keystore "/opt/java64/1.7.0_72/jre/lib/security/cacerts" -storepass changeit некорректная, т.к. вы указали провайдер JCP, а работаете с cacerts, который имеет формат JKS, совершенно незнакомый JCP. Команды для работы с ключами и сертификатами лучше смотреть в руководствах разработчика и администратора в папке Doc дистрибутива, и будут они только с форматами, реализованными в JCP. Команда: Код: C:Javajdk1.7.0_79jrebinkeytool -importcert -file "certnew.cer" -alias CryptoPro_CA -keystore "C:Javajdk1.7.0_79jrelibsecuritycacerts" -storepass changeit корректная, т.к. java все равно, какой сертификат устанавливается, и провайдер используется по умолчанию (для JKS). 2. Цитата: При попытке получить информацию о сертификате из cacerts он его находит, но выдает ошибку. /opt/java64/1.7.0_72/jre/bin/keytool -list -v -keystore «/opt/java64/1.7.0_72/jre/lib/security/cacerts» -alias CryptoPro_CA keytool error: java.security.cert.CertificateException: Certificate contains invalid public key: Unrecognized public key. java.security.cert.CertificateException: Certificate contains invalid public key: Unrecognized public key. at com.rsa.cryptoj.o.pk.g(Unknown Source) at com.rsa.cryptoj.o.pk.<init>(Unknown Source) at com.rsa.cryptoj.o.pj.<init>(Unknown Source) at com.rsa.cryptoj.o.pg.a(Unknown Source) at com.rsa.cryptoj.o.ot.engineGenerateCertificate(Unknown Source) at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:339) В работу вмешивается какой-то провайдер com.rsa.cryptoj. Отредактировано пользователем 10 июля 2020 г. 15:58:02(UTC)  | Причина: Не указана
Тех. поддержка База знаний Логирование JCP Логирование JTLS Тест JCP и сбор диаг. информации Скачать JCP, JCSP и JTLS Скачать Android CSP + SDK

AlexanderOT1	#5 Оставлено : 13 июля 2020 г. 23:01:30(UTC)
Статус: Участник Группы: Участники Зарегистрирован: 05.06.2020(UTC) Сообщений: 25 Сказал(а) «Спасибо»: 3 раз	Спасибо, действительно, в jrelibsecurityjava.security есть регистрация нестандартного провайдера. Может быть есть общие рекомендации, как разрешить этот конфликт, без отключения провайдера? Судя по всему, провайдер нужен для другого компонента системы.

Евгений Афанасьев	#6 Оставлено : 14 июля 2020 г. 10:14:06(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,740 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 647 раз в 610 постах	Попробуйте указывать провайдер в keytool. Но надо учесть, что это не всегда помогает, так как, например, в случае декодирования открытого ключа сертификата поиск подходящего провайдера происходит по признаку, может ли этот провайдер декодировать ключ (поддерживает ли OID алгоритма ключа), и тогда важно положение провайдера в списке java.security (первый подходящий из списка будет декодировать). Обычно работу с ключами на иностранных алгоритмах обеспечивает встроенный провайдер типа Sun. Возможно, в списке java.security провайдер com.rsa.cryptoj (судя по названию пакета, он работает с иностранными алгоритмами) находится в начале списка и потому перехватывает обращения keytool к сертификату. Попробуйте переместить com.rsa.cryptoj в конец списка в java.security, сохраняя правильную нумерацию. Отредактировано пользователем 14 июля 2020 г. 10:16:00(UTC)  | Причина: Не указана
Тех. поддержка База знаний Логирование JCP Логирование JTLS Тест JCP и сбор диаг. информации Скачать JCP, JCSP и JTLS Скачать Android CSP + SDK

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

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

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

На работе мы обычно используем следующие две команды, чтобы какое-то программное обеспечение могло взаимодействовать с различными серверами, например, чтобы позволить IntelliJ IDEA взаимодействовать с нашими внутренними репозиториями maven:

[Elevated]keytool 
    -printcert -rfc -sslserver maven.services.{our-company}.com:443 > public.crt

[Elevated]keytool
    -import -storepass changeit -noprompt -trustcacerts -alias services.{our-company}.com 
    -keystore libsecuritycacerts -file public.crt

Иногда случается, что keytool -printcert команда не может выполнять свою работу либо из-за неправильной конфигурации, либо просто из-за временных проблем с подключением, таких как брандмауэр, препятствующий этому, пользователь забыл запустить свою VPN и т. д. Это факт жизни, что это может случиться. На самом деле проблема не в этом.

Проблема в том, что когда глупый инструмент обнаруживает такую ​​ошибку, он не выдает сообщение об ошибке на стандартное устройство ошибки, а выдает его на стандартное устройство вывода!

Итак, вот что в итоге происходит:

• Когда вы выполняете первую команду, вы не видите сообщения об ошибке, поэтому вы не знаете, что это не удалось. Однако вместо ключа public.crt файл теперь содержит сообщение об ошибке keytool error: java.lang.Exception: No certificate from the SSL server.
• Когда вы выполняете вторую команду, она читает public.crt и он находит в нем текст сообщения об ошибке вместо ключа, поэтому он терпит неудачу, говоря keytool error: java.lang.Exception: Input not an X.509 certificate.

Итог: после keytool -printcert ... > public.crt всегда выгружать содержимое public.crt чтобы убедиться, что это действительно ключ, а не сообщение об ошибке, прежде чем продолжить keytool -import ... -file public.crt

Добрый день!
Использую rancher, в нем развернут Kubernetes.
С помощью gitlab-ci пытаюсь развернуть там приложения
Ниже конфиг kubernetes

apiVersion: v1
kind: Config
clusters:
- name: "kubernetes-apatsev"
  cluster:
    server: "https://rancher.xxx/k8s/clusters/c-z68kj"
    insecure-skip-tls-verify: true
    api-version: v1
    certificate-authority-data: "............"

users:
- name: "u-qwqsh"
  user:
    token: "kubeconfig-u-qwqsh:......"

contexts:
- name: "kubernetes-apatsev"
  context:
    user: "u-qwqsh"
    cluster: "kubernetes-apatsev"

current-context: "kubernetes-apatsev"

В gitlab-ci выполняю:

- echo | openssl s_client -servername rancher.xxxx -connect yyyy:443 2>/dev/null | openssl x509 -noout -dates
    - kubectl -n $NAMESPACE get pod

Выдает ошибку:

Error: could not get Kubernetes client: specifying a root certificates file with the insecure flag is not allowed

Если не использовать строку insecure-skip-tls-verify: true, то
helm install stable/postgresql .....
выдаст ошибку:

Error: Get https://rancher.xxxxx/k8s/clusters/c-z68kj/api/v1/namespaces/kube-system/pods?labelSelector=app%3Dhelm%2Cname%3Dtiller: x509: certificate signed by unknown authority

Как исправить ошибку?

6 ответов

Лучший ответ

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

[Elevated]keytool 
    -printcert -rfc -sslserver maven.services.{our-company}.com:443 > public.crt

[Elevated]keytool
    -import -storepass changeit -noprompt -trustcacerts -alias services.{our-company}.com 
    -keystore libsecuritycacerts -file public.crt

Я также добавлю сюда свой опыт, если он кому-нибудь поможет:

На работе мы обычно используем следующие две команды, чтобы позволить IntelliJ IDEA взаимодействовать с различными серверами, например, с нашими внутренними репозиториями maven:

[Elevated]C:Program FilesJetBrainsIntelliJ IDEA {version}jre64>binkeytool 
    -printcert -rfc -sslserver maven.services.{our-company}.com:443 > public.crt

[Elevated]C:Program FilesJetBrainsIntelliJ IDEA {version}jre64>binkeytool
    -import -storepass changeit -noprompt -trustcacerts -alias services.{our-company}.com 
    -keystore libsecuritycacerts -file public.crt

Теперь иногда случается, что команда keytool -printcert не может установить связь с внешним миром из-за временных проблем с подключением, таких как брандмауэр, препятствующий этому, пользователь забыл запустить VPN, что угодно. Это факт жизни, что это может произойти. Это на самом деле не проблема.

Проблема в том, что, когда тупой инструмент встречает такую ошибку, он не выдает сообщение об ошибке на стандартное устройство ошибки, он отправляет его на стандартное устройство вывода!

Итак, вот что в итоге происходит:

• Когда вы выполняете первую команду, вы не видите никакого сообщения об ошибке, поэтому вы не знаете, что оно не удалось. Однако вместо ключа файл public.crt теперь содержит сообщение об ошибке, в котором говорится keytool error: java.lang.Exception: No certificate from the SSL server.
• Когда вы выполняете вторую команду, она находит сообщение об ошибке вместо ключа в public.crt, поэтому происходит сбой, сообщая keytool error: java.lang.Exception: Input not an X.509 certificate.

Итог: после keytool -printcert... > public.crt всегда keytool -printcert... > public.crt содержимое public.crt чтобы удостовериться, что это действительно ключ, а не сообщение об ошибке, прежде чем приступить к запуску keytool -import... -file public.crt

@Carmeloning证书验证失败可能由于多种原因而发生。例如，您尚未设置正确的受信任根证书。证书验证失败时返回
错误-0x2700 MBEDTLS_ERR_X509_CERT_VERIFY_FAILED并返回。
您还应该检查验证标志。
I used the server to give me the root certificate in the browser test and the server handshake is able to pass，But when i use the Mbed. IT is faild and it return like this：
Starting mbed-os-example-tls/tls-client
Using Mbed OS 5.9.7
[EasyConnect] IPv4 mode
[EasyConnect] Using WiFi (ESP8266)
[EasyConnect] Connecting to WiFi GE
[EasyConnect] Connected to Network successfully
[EasyConnect] MAC address 84:0d:8e:97:40:ca
[EasyConnect] IP address 192.168.1.15
Successfully connected to 39.108.211.173 at port 443
Starting the TLS handshake…
ssl_tls.c:6717: |2| => handshake

ssl_cli.c:3386: |2| client state: 0

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2483: |2| <= flush output

ssl_cli.c:3386: |2| client state: 1

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2483: |2| <= flush output

ssl_cli.c:770: |2| => write client hello

ssl_tls.c:2764: |2| => write record

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2489: |2| message length: 189, out_left: 189

ssl_tls.c:2496: |2| ssl->f_send() returned 189 (-0xffffff43)

ssl_tls.c:2523: |2| <= flush output

ssl_tls.c:2922: |2| <= write record

ssl_cli.c:1085: |2| <= write client hello

ssl_cli.c:3386: |2| client state: 2

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2483: |2| <= flush output

ssl_cli.c:1478: |2| => parse server hello

ssl_tls.c:3809: |2| => read record

ssl_tls.c:2252: |2| => fetch input

ssl_tls.c:2412: |2| in_left: 0, nb_want: 5

ssl_tls.c:2436: |2| in_left: 0, nb_want: 5

ssl_tls.c:2438: |2| ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)

ssl_tls.c:2458: |2| <= fetch input

ssl_tls.c:2252: |2| => fetch input

ssl_tls.c:2412: |2| in_left: 5, nb_want: 66

ssl_tls.c:2436: |2| in_left: 5, nb_want: 66

ssl_tls.c:2438: |2| ssl->f_recv(_timeout)() returned 61 (-0xffffffc3)

ssl_tls.c:2458: |2| <= fetch input

ssl_tls.c:3846: |2| <= read record

ssl_cli.c:1760: |2| server hello, total extension length: 17

ssl_cli.c:1949: |2| <= parse server hello

ssl_cli.c:3386: |2| client state: 3

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2483: |2| <= flush output

ssl_tls.c:4376: |2| => parse certificate

ssl_tls.c:3809: |2| => read record

ssl_tls.c:2252: |2| => fetch input

ssl_tls.c:2412: |2| in_left: 0, nb_want: 5

ssl_tls.c:2436: |2| in_left: 0, nb_want: 5

ssl_tls.c:2438: |2| ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)

ssl_tls.c:2458: |2| <= fetch input

ssl_tls.c:2252: |2| => fetch input

ssl_tls.c:2412: |2| in_left: 5, nb_want: 877

ssl_tls.c:2436: |2| in_left: 5, nb_want: 877

ssl_tls.c:2438: |2| ssl->f_recv(_timeout)() returned 872 (-0xfffffc98)

ssl_tls.c:2458: |2| <= fetch input

ssl_tls.c:3846: |2| <= read record

Verifying certificate at depth 0:

cert. version : 1

serial number : 8D:9E:62:C5:CC:7A:BA:B6

issuer name : C=CN, ST=myprovince, L=mycity, O=myorganization, OU=mygroup, CN=myCA

subject name : C=CN, ST=myprovince, L=mycity, O=myorganization, OU=mygroup, CN=myServer

issued on : 2019-01-14 02:25:20

expires on : 2020-01-14 02:25:20

signed using : RSA with SHA1

RSA key size : 2048 bits

ssl_tls.c:4643: |1| x509_verify_cert() returned -9984 (-0x2700)

ssl_tls.c:4180: |2| => send alert message

ssl_tls.c:2764: |2| => write record

ssl_tls.c:2471: |2| => flush output

ssl_tls.c:2489: |2| message length: 7, out_left: 7

ssl_tls.c:2496: |2| ssl->f_send() returned 7 (-0xfffffff9)

ssl_tls.c:2523: |2| <= flush output

ssl_tls.c:2922: |2| <= write record

ssl_tls.c:4193: |2| <= send alert message

ssl_tls.c:4740: |2| <= parse certificate

ssl_tls.c:6727: |2| <= handshake

mbedtls_ssl_handshake() returned -0x2700

FAIL
ssl_tls.c:7495: |2| => free

ssl_tls.c:7560: |2| <= free