SSLError를 던지는 Python 요청
CAS, jspring 보안 검사, 리디렉션 등을 포함하는 간단한 스크립트를 작성하고 있습니다. Kenneth Reitz의 python 요청은 훌륭한 작업이므로 사용하고 싶습니다! 그러나 CAS는 SSL을 통해 유효성을 검사해야하므로 해당 단계를 먼저 거쳐야합니다. 파이썬 요청이 무엇을 원하는지 모르겠습니까? 이 SSL 인증서는 어디에 있어야합니까?
Traceback (most recent call last):
File "./test.py", line 24, in <module>
response = requests.get(url1, headers=headers)
File "build/bdist.linux-x86_64/egg/requests/api.py", line 52, in get
File "build/bdist.linux-x86_64/egg/requests/api.py", line 40, in request
File "build/bdist.linux-x86_64/egg/requests/sessions.py", line 209, in request
File "build/bdist.linux-x86_64/egg/requests/models.py", line 624, in send
File "build/bdist.linux-x86_64/egg/requests/models.py", line 300, in _build_response
File "build/bdist.linux-x86_64/egg/requests/models.py", line 611, in send
requests.exceptions.SSLError: [Errno 1] _ssl.c:503: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
신뢰할 수없는 SSL 인증서로 인해 발생한 문제입니다.
이전 의견에서 언급 한 @dirk와 마찬가지로 가장 빠른 수정은 설정입니다 verify=False.
requests.get('https://example.com', verify=False)
이로 인해 인증서가 확인되지 않습니다. 이렇게하면 중간자 공격과 같은 보안 위험에 응용 프로그램이 노출됩니다.
물론 판단을 적용하십시오. 의견에서 언급했듯이, 이것은 빠른 / throwaway 응용 프로그램 / 스크립트에 허용 될 수 있지만 실제로는 프로덕션 소프트웨어로 가면 안됩니다 .
특정 상황에서 인증서 검사를 건너 뛸 수없는 경우 다음 옵션을 고려하십시오. 가장 좋은 옵션은 verify매개 변수를 .pem인증서 파일의 경로 인 문자열 로 설정하는 것입니다. 방법).
따라서 버전 2.0부터 verify매개 변수는 각각의 의미와 함께 다음 값을 승인합니다.
True: 라이브러리 자체의 신뢰할 수있는 인증 기관에 대해 인증서의 유효성을 검사합니다 (참고 : Requests : Certifi-Trust Database for Humans 에서 추출한 RC의 트러스트 데이터베이스 인 Certifi 라이브러리를 통해 어떤 루트 인증서 요청이 사용하는지 확인할 수 있습니다 ).False: 인증서 유효성 검사를 완전히 무시합니다 .- 요청이 인증서를 검증하는 데 사용할 CA_BUNDLE 파일의 경로입니다.
출처 : 요청-SSL 인증서 확인
또한 cert동일한 링크 의 매개 변수를 살펴보십시오 .
요청은 웹 브라우저와 마찬가지로 HTTPS 요청에 대한 SSL 인증서를 확인할 수 있습니다. 호스트의 SSL 인증서를 확인하려면 verify 인수를 사용할 수 있습니다.
>>> requests.get('https://kennethreitz.com', verify=True)
SSL 인증서를 확인하지 않으려면 verify=False
사용할 CA 파일 이름은 verify다음을 통해 전달할 수 있습니다 .
cafile = 'cacert.pem' # http://curl.haxx.se/ca/cacert.pem
r = requests.get(url, verify=cafile)
verify=True그런 다음 requests사용하는 경우 서버 인증서에 서명 한 CA가없는 자체 CA 세트 를 사용하십시오.
$ pip install -U requests[security]
- Python 2.7.6 @ Ubuntu 14.04.4 LTS에서 테스트
- MacOSX 10.9.5 @ Python 2.7.5에서 테스트 (매버릭스)
이 질문이 열렸을 때 (2012-05) 요청 버전은 0.13.1입니다. 버전 2.4.1 (2014-09) 에서 "보안"추가 기능이 사용 certifi가능한 경우 패키지를 사용하여 도입되었습니다 .
지금 (2016-09)의 주요 버전은 좋은 작품을, 2.11.1입니다 없이 verify=False . 엑스트라 requests.get(url, verify=False)가 설치된 requests[security]경우을 사용할 필요가 없습니다 .
boto3 코드를 검토하여 aws boto3을 사용할 때 동일한 문제가 발생하고 SSL 인증서 확인 실패 문제 REQUESTS_CA_BUNDLE가 설정되지 않았으므로 수동으로 설정하여 두 문제를 해결했습니다.
from boto3.session import Session
import os
# debian
os.environ['REQUESTS_CA_BUNDLE'] = os.path.join(
'/etc/ssl/certs/',
'ca-certificates.crt')
# centos
# 'ca-bundle.crt')
aws-cli의 경우 REQUESTS_CA_BUNDLE을 설정 ~/.bashrc하면이 문제가 해결됩니다 (aws-cli가 작동하지 않으므로 테스트되지 않음).
REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt # ca-bundle.crt
export REQUESTS_CA_BUNDLE
의존하는 라이브러리가 requests있고 확인 경로를 (와 같이 pyvmomi) 수정할 수없는 경우 cacert.pem요청과 함께 번들 을 찾아 CA를 추가해야합니다. cacert.pem위치 를 찾는 일반적인 방법은 다음과 같습니다 .
창문
C:\>python -c "import requests; print requests.certs.where()"
c:\Python27\lib\site-packages\requests-2.8.1-py2.7.egg\requests\cacert.pem
리눅스
# (py2.7.5,requests 2.7.0, verify not enforced)
root@host:~/# python -c "import requests; print requests.certs.where()"
/usr/lib/python2.7/dist-packages/certifi/cacert.pem
# (py2.7.10, verify enforced)
root@host:~/# python -c "import requests; print requests.certs.where()"
/usr/local/lib/python2.7/dist-packages/requests/cacert.pem
btw. @ requests-devs, 요청과 함께 자신의 cacerts를 번들로 묶는 것은 정말 성가신 일입니다. 특히 시스템 ca 저장소를 먼저 사용하지 않는 것으로 보이며 이것은 어디에도 문서화되어 있지 않습니다.
최신 정보
라이브러리를 사용하고 ca 번들 위치를 제어 할 수없는 경우 ca 번들 위치를 호스트 전체 ca 번들로 명시 적으로 설정할 수도 있습니다.
REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-bundle.crt python -c "import requests; requests.get('https://somesite.com';)"
나는 gspread를 사용하여 같은 문제에 직면하고 있으며 이러한 명령은 저에게 효과적입니다.
sudo pip uninstall -y certifi
sudo pip install certifi==2015.04.28
경고를 제거하려면 아래 코드를 사용하십시오.
import urllib3
urllib3.disable_warnings()
와 verify=False함께 request.get또는 post방법
비슷한 문제를 해결하기위한 구체적인 접근 방식을 찾았습니다. 아이디어는 시스템에 저장되어 있고 다른 SSL 기반 응용 프로그램에서 사용되는 cacert 파일을 가리키고 있습니다.
데비안에서는 (다른 배포판에서 같은지 확실하지 않습니다) 인증서 파일 (.pem)이 저장되어 있습니다 /etc/ssl/certs/. 이것은 저에게 효과적입니다.
import requests
verify='/etc/ssl/certs/cacert.org.pem'
response = requests.get('https://lists.cacert.org', verify=verify)
어떤 pem파일을 선택 했는지 추측 하기 위해 URL을 찾아서 어떤 인증 기관 (CA)이 인증서를 생성했는지 확인했습니다.
편집 : 코드를 편집 할 수없는 경우 (세 번째 응용 프로그램을 실행 중이기 때문에) pem인증서를 직접 추가 /usr/local/lib/python2.7/dist-packages/requests/cacert.pem(예 : 파일 끝에 복사 ) 할 수 있습니다 .
인증서를 신경 쓰지 않으면을 사용하십시오 verify=False.
import requests
url = "Write your url here"
returnResponse = requests.get(url, verify=False)
몇 시간의 디버깅 후에 다음 패키지를 사용 하여이 작업을 수행 할 수있었습니다.
requests[security]==2.7.0 # not 2.18.1
cryptography==1.9 # not 2.0
사용 OpenSSL 1.0.2g 1 Mar 2016
이 패키지 verify=False가 없으면 작동하지 않았습니다.
나는 이것이 누군가를 돕기를 바랍니다.
나는 같은 문제에 부딪쳤다. 서버에 중간 인증서를 설치하지 않은 것으로 나타났습니다 (아래 그림과 같이 인증서 하단에 추가하십시오).
https://www.digicert.com/ssl-support/pem-ssl-creation.htm
ca-certificates 패키지가 설치되어 있는지 확인하십시오.
sudo apt-get install ca-certificates
시간을 업데이트하면이 문제를 해결할 수도 있습니다.
sudo apt-get install ntpdate
sudo ntpdate -u ntp.ubuntu.com
자체 서명 된 인증서를 사용하는 경우 시스템에 수동으로 인증서를 추가해야합니다.
요청 호출이 코드 어딘가에 묻혀 있고 서버 인증서를 설치하지 않으려는 경우 디버그 목적으로 만 요청을 몽키 패치 할 수 있습니다.
import requests.api
import warnings
def requestspatch(method, url, **kwargs):
kwargs['verify'] = False
return _origcall(method, url, **kwargs)
_origcall = requests.api.request
requests.api.request = requestspatch
warnings.warn('Patched requests: SSL verification disabled!')
생산에는 절대 사용하지 마십시오!
HOURS에서이 문제를 해결했습니다.
요청을 업데이트하려고했습니다. 그런 다음 인증을 업데이트했습니다. certifi.where ()를 확인하도록 지시했습니다 (코드는 기본적 으로이 작업을 수행합니다). 아무것도 효과가 없었습니다.
마지막으로 파이썬 버전을 python 2.7.11로 업데이트했습니다. 인증서를 확인하는 방식과 일부 호환되지 않는 Python 2.7.5를 사용했습니다. 파이썬 (및 소수의 다른 의존성)을 업데이트하면 작동하기 시작했습니다.
v2.6.2 ~ v2.12.4 (ATOW)에 현재이 오류를 발생시키는 요청 모듈에 문제가 있습니다. https://github.com/kennethreitz/requests/issues/2573
이 문제에 대한 해결 방법은 다음 줄을 추가하는 것입니다. requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS = 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS'
@Rafael Almeida가 언급했듯이 신뢰할 수없는 SSL 인증서로 인해 문제가 발생합니다. 필자의 경우 서버에서 SSL 인증서를 신뢰할 수 없습니다. 보안을 손상시키지 않고이 문제를 해결하려면 인증서를 다운로드하여 서버에 설치했습니다 (.crt 파일을 두 번 클릭 한 다음 인증서 설치 ...).
내가 생각하는 파티에 너무 늦었지만 나와 같은 동료 방랑자를 위해 고침을 붙여 넣고 싶었습니다! 그래서 다음은 Python 3.7.x에서 나를 위해 일했습니다.
터미널에 다음을 입력하십시오
pip install --upgrade certifi # hold your breath..
스크립트 / 요청을 다시 실행하고 작동하는지 확인하십시오 (아직 수정되지 않았을 것입니다). 작동하지 않으면 터미널에서 다음 명령을 직접 실행하십시오.
open /Applications/Python\ 3.6/Install\ Certificates.command # please replace 3.6 here with your suitable python version
다른 패키지에서 요청을 호출하는 경우 옵션을 추가 할 수 없습니다. 이 경우 cacert 번들에 인증서를 추가하는 것은 간단한 방법입니다. 예를 들어 "StartCom Class 1 주 중급 서버 CA"를 추가해야했습니다.이 루트 루트 인증서를 StartComClass1.pem에 다운로드했습니다. 내 virtualenv의 이름이 caldav 인 경우 인증서를 다음과 같이 추가했습니다.
cat StartComClass1.pem >> .virtualenvs/caldav/lib/python2.7/site-packages/pip/_vendor/requests/cacert.pem
cat temp/StartComClass1.pem >> .virtualenvs/caldav/lib/python2.7/site-packages/requests/cacert.pem
그 중 하나는 충분할 수 있습니다, 나는 확인하지 않았다
비슷한 인증 유효성 검사 문제가 발생했습니다. 요청이 때로는 강력한 인증서를 확인하는 데 문제가있는 1.0.2 미만의 OpenSSL 버전을 읽었습니다 ( 여기 참조 ). CentOS 7은 1.0.1e를 사용하는 것으로 보이며 문제가있는 것 같습니다.
CentOS에서이 문제를 해결하는 방법을 잘 모르겠으므로 약한 1024 비트 CA 인증서를 허용하기로 결정했습니다.
import certifi # This should be already installed as a dependency of 'requests'
requests.get("https://example.com", verify=certifi.old_where())
파이썬 3.4.0에서 3.4.6으로 업그레이드해야했습니다.
pyenv virtualenv 3.4.6 myvenv
pyenv activate myvenv
pip install -r requirements.txt
제 경우에는 그 이유가 아주 사소했습니다.
SSL 확인이 며칠 전까지 작동했으며 실제로 다른 시스템에서 작업하고 있음을 알고있었습니다.
다음 단계는 인증이 작동하는 시스템과 작동하지 않는 시스템의 인증서 내용과 크기를 비교하는 것입니다.
이로 인해 '정확하지 않은'작업 기계의 인증서가 좋지 않다고 판단하고 일단 '좋은'인증서로 교체하면 모든 것이 정상이었습니다.
참고 URL : https://stackoverflow.com/questions/10667960/python-requests-throwing-sslerror
'development' 카테고리의 다른 글
| 렉서 vs 파서 (0) | 2020.03.16 |
|---|---|
| iframe 작업에서 부모 창 리디렉션 (0) | 2020.03.16 |
| 정적 / 동적 vs 강 / 약 (0) | 2020.03.16 |
| R 및 RStudio에서 콘솔을 지우는 기능 (0) | 2020.03.16 |
| 유형 또는 네임 스페이스 이름이 존재하지 않습니다. (0) | 2020.03.16 |