У нас есть общедоступный сервер разработки, который требует SSL для определенной функции.
Тем не менее, ВСЕ, что использует SSL в любой форме возвращает
curl: (60) Peer's certificate issuer has been marked as not trusted by the user.
Это не проблема типа «Просто используйте ssl-verify = false для yum или --insecure для запросов curl.
Я понимаю, что могу сделать это для обоих из них, чтобы выполнить свои звонки. Но в конечном итоге - я ДОЛЖЕН иметь возможность использовать SSL, потому что разработка, для которой мы используем эти серверы, требует этого.
Кажется, что CA устарел. Я пробовал следующее https://access.redhat.com/solutions/1549003
Я сам пробовал импортировать файл cacert.pem (хотя признаю, что мне здесь не хватает знаний, возможно, я сделал это неправильно )
Я проверил дату / время на сервере, чтобы убедиться, что проблема не в этом.
Я не могу получить "Сетевой администратор" (термин используется нечетко, так как он будет первым, кто признает, что абсолютно без знания Linux - чистый Microsoft), чтобы даже возиться с переустановкой Centos на эту машину, поэтому мне нужно найти решение этой проблемы.
Любая помощь будет принята с благодарностью. Ниже приведены некоторые примеры того, что мы получаем, пытаясь выполнить такие действия, как yum, curl и запуск certbot --apache
YUM
[root@localhost work]# yum reinstall mc
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=epel-
7&arch=x86_64 error was
14: curl#60 - "Peer's certificate issuer has been marked as not trusted by
the user."
* base: repos.dfw.quadranet.com
* epel: mirror.compevo.com
* extras: repos-tx.psychz.net
* updates: mirror.us.oneandone.net
* webtatic: repo.webtatic.com
https://us-east.repo.webtatic.com/yum/el7/x86_64/repodata/repomd.xml: [Errno
14] curl#60 - "Peer's certificate issuer has been marked as not trusted by
the user."
Trying other mirror.
It was impossible to connect to the CentOS servers.
This could mean a connectivity issue in your environment, such as the
requirement to configure a proxy,
or a transparent proxy that tampers with TLS security, or an incorrect
system clock.
You can try to solve this issue by using the instructions on
https://wiki.centos.org/yum-errors
If above article doesn't help to resolve this issue please use
https://bugs.centos.org/.
https://uk.repo.webtatic.com/yum/el7/x86_64/repodata/repomd.xml: [Errno 14]
curl#60 - "Peer's certificate issuer has been marked as not trusted by the
user."
Trying other mirror.
https://sp.repo.webtatic.com/yum/el7/x86_64/repodata/repomd.xml: [Errno 14]
curl#60 - "Peer's certificate issuer has been marked as not trusted by the
user."
Trying other mirror.
https://repo.webtatic.com/yum/el7/x86_64/repodata/repomd.xml: [Errno 14]
curl#60 - "Peer's certificate issuer has been marked as not trusted by the
user."
Trying other mirror.
CURL
[root@localhost work]# curl https://www.google.com
curl: (60) Peer's certificate issuer has been marked as not trusted by the
user.
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
CERTBOT (ДЛЯ ЗАПРОСА LETSENCRYPT SSL CERT)
[root@localhost work]# sudo certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Enter email address (used for urgent renewal and security notices) (Enter
'c' to cancel): email@host.com
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
An unexpected error occurred:
SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
(_ssl.c:579)
Please see the logfiles in /var/log/letsencrypt for more details.
Хотел ответить и закрыть это на будущее.
Оказывается, у нас действительно был прокси-сервер, который возился с вещами. У нас довольно интересная ситуация на моей работе (3 компании, 2 принадлежат одному владельцу моей компании отдельно от моей собственной компании).
Оказывается, системный администратор компании B включил прокси-сервер в цикл x много лет назад и забыл об этом. Введите системного администратора моей компании, который берет на себя всю роль системного администратора для всех компаний. Никто ему не говорит о прокси. Он работал годами без ведома никого.
мой здесь находится в CentOS7, запустите pyspider
показать ошибку:
Исключение HTTP 599 Издатель сертификата партнера был помечен как недоверенный пользователем
и использует следующие шаги, чтобы исправить это:
заменить недопустимый файл libcurl .so:
/usr/lib64/libcurl.so.4 -> libcurl.so.4.3.0_openssl
на действительный файл libcurl .so:
/usr/lib64/libcurl.so.4 -> libcurl.so.4.3.0
и переустановите pycurl:
pip3 uninstall pycurl
export PYCURL_SSL_LIBRARY=nss
export LDFLAGS=-L/usr/local/opt/openssl/lib;export CPPFLAGS=-I/usr/local/opt/openssl/include;pip install pycurl --compile --no-cache-dir
подробное описание см. другой пост SO
Дифференциальная диагностика проблемы
Как смягчить проблему с одноранговым сертификатом, скажем, я устанавливаю PHP 7.4 с помощью репозитория remi-php74, что можно сделать, чтобы избежать всех проблем, связанных с диагностикой:>
Самостоятельно срок действия подписанного сертификата истек
yum-config-manager --save --setopt=remi-php74.skip_if_unavailable=true
yum-config-manager --save --setopt=remiphp74.ssl_check_cert_permissions=false
Репозиторий использование ссылок https для загрузки
grep 'baseurl' /etc/yum.repos.d/* | grep php
vi /etc/yum.repos.d/remi-php74.repo
Отредактируйте URL-адреса, прокомментируйте те, которые используют https, раскомментируйте http для базового URL-адреса или списка зеркал, чтобы убедиться, что проблема с одноранговым сертификатом не всплывает
Прокси-сервер не настроен для данных ссылок, используемых baseurl
yum-config-manager --save --setopt=remiphp74.proxy= https://proxy_ip:proxy_port
Прокси http и https не настроены для скачивания пакетов
export http_proxy=http://proxy_ip:proxy_port
export https_proxy=https://proxy_ip:proxy_port
] Шаг за шагом, что необходимо сделать, если вы столкнулись с определенным репозиторием и его доступным списком установки:>
Проверить доступность репо, используя:>
Yum repolist
Проверить необходимое репо и отключить все остальные:>
yum list available --disablerepo=* --enablerepo=remi-php74
yum-config-manager --enable remi-php74
Если проблема с одноранговым сертификатом сохранить параметр репо:>
yum-config-manager --save --setopt=remi-php74.skip_if_unavailable=true
yum-config-manager --save --setopt=remiphp74.ssl_check_cert_permissions=false
Если есть какие-либо проблемы с URL-адресами, проверьте, что базовый URL-адрес находится в http, поэтому снимите их в файле репо нужного репо:>
grep 'baseurl' /etc/yum.repos.d/* | grep php
Отредактируйте необходимый репозиторий для изменения базового URL-адреса с http, чтобы избежать однорангового проблема с сертификатом
vi /etc/yum.repos.d/remi-php74.repo
Установите необходимый пакет:>
Yum install php
Эта процедура применяется ко всем другим установкам с использованием необходимого репозитория. Нет необходимости получать сертификат ЦС, если проблема заключается в установке пакетов и возникает проблема с одноранговым сертификатом. Также добавьте DNS, если проблема не устранена. с точки зрения невозможности разрешить URL-адреса, так как google dns помогает gre После разрешения базовых URL-адресов, используемых пакетами ниже, помогает, если оно настроено.
в /etc/resolv.conf добавить записи ниже
nameserver 8.8.8.8
nameserver 8.8.4.4