Comments
drwetter
added a commit
that referenced
this issue
May 18, 2018
My previous commit added a host header but didn't properly format the host header (trailing slashes / path). This commit corrects that so that the 305 times HTTP 400 in #1056 should now be gone (TBC), including Google CA responders. One issue which needs to be addressed (same as in CRL revocation checks): Not trusted certificates (zhanqi.tv, taken from my Alexa scans) fail for obvious reasons.
dcooper16
added a commit
to dcooper16/testssl.sh
that referenced
this issue
May 29, 2018
This PR fixes problems with check_revocation_crl() sometimes reporting that a certificate is revoked even when it isn't, and with check_revocation_ocsp() sometimes reporting "error querying OCSP responder" even if the OCSP responder provided a good response. The most common reason for this to happen is that OpenSSL cannot validate the server's certificate (even without status checking). PR drwetter#1051 attempted to get status checking to work even in cases in which the server's certificate could not be validated. This PR instead addresses the problem by not checking status if determine_trust() was unable to validate the server's certificate. In some cases the server's certificate can be validated using some, but not all of the bundles of trusted certificates. For example, I have encountered some sites that can be validated using the Microsoft and Apple bundles, but not the Linux or Mozilla bundles. This PR introduces GOOD_CA_BUNDLE to store a bundle that could be used to successfully validate the server's certificate. If there is no such bundle, then neither check_revocation_crl() nor check_revocation_ocsp() is run. When check_revocation_crl() and check_revocation_ocsp() are called, the status checks within them closely match the validation check in determine_trust(), which helps to ensure that if the check fails it is because of the status information. As noted in drwetter#1057, at least one CA provides incorrect information when the CRL is downloaded, so validation could fail for a reason other than the certificate being revoked. So, this PR adds a check of the reason that validation failed and only reports "revoked" if the validation failed for that reason. As noted in drwetter#1056, it is not possible to perform an OCSP query without access to the certificate issuer's public key. So, with this PR check_revocation_ocsp() is only called if the server's provided at least one intermediate certificate (i.e., the issuer's certificate, which contains the issuer's public key).
plov |
|
|
Статус: Участник Группы: Участники
|
У меня есть отделенная подпись и оригинал файла, из подписи я извлкаю сертификат и пытаюсь проверить на oсsp сервере его актуальность утилитой, в ответ получаю «Error querying OCSP responder» без описания ошибки. Issuer сертификата — комания Тензор, в свою очередь её issuer — криптопро. Вот мой «путь»: 2) Парсю вывод команды 3) Конвертирую в PEM: 4) Скачиваю http://cpca.cryptopro.ru/cacer.p7b, конвертирую в PEM 5) Получаю урл OCSP сервера: 6) openssl ocsp -CAfile cacer.pem -issuer issuer.pem -cert mycert.pem -url http://tax4.tensor.ru/ocsp/ocsp.srf 6.1) С чего я взял, что криптопро тут участвует? 1.2.643.100.112: ИТОГ: Почему я не могу проверить сертификат? Может, я скармливаю OCSP программе не те сертификаты или ссылки? Если так, то что надо скармливать? Отредактировано пользователем 9 мая 2015 г. 21:05:56(UTC) Вложение(я):
У Вас нет прав для просмотра или загрузки вложений. Попробуйте зарегистрироваться. |
 |
|
message.rar |
Андрей Писарев |
|
|
Статус: Сотрудник Группы: Участники Сказал «Спасибо»: 451 раз |
Автор: plov У меня есть отделенная подпись и оригинал файла, из подписи я извлкаю сертификат и пытаюсь проверить на oсsp сервере его актуальность утилитой, в ответ получаю «Error querying OCSP responder» без описания ошибки. Issuer сертификата — комания Тензор, в свою очередь её issuer — криптопро. Вот мой «путь»: 2) Парсю вывод команды 3) Конвертирую в PEM: 4) Скачиваю http://cpca.cryptopro.ru/cacer.p7b, конвертирую в PEM 5) Получаю урл OCSP сервера: 6) openssl ocsp -CAfile cacer.pem -issuer issuer.pem -cert mycert.pem -url http://tax4.tensor.ru/ocsp/ocsp.srf 6.1) С чего я взял, что криптопро тут участвует? 1.2.643.100.112: ИТОГ: Почему я не могу проверить сертификат? Может, я скармливаю OCSP программе не те сертификаты или ссылки? Если так, то что надо скармливать? Приказ ФСБ РФ от 27 декабря 2011 г. № 795 «Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи» Вывод: УЦ Тензора функционирует на базе ПО от ООО КРИПТО-ПРО. |
|
Техническую поддержку оказываем тут |
|
|
|
WWW |
|
plov |
|
|
Статус: Участник Группы: Участники
|
Прекрасно, в этом я не ошибся. А что насчёт остальных пунктов моего вопроса? UPDATE: Отредактировано пользователем 12 мая 2015 г. 20:19:38(UTC) |
|
|
|
| Пользователи, просматривающие эту тему |
|
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
29434
Created On 09/25/18 15:19 PM — Last Modified 08/03/20 22:20 PM
Symptom
Panorama had been displaying the cloud logging service service logs, and then suddenly stops displaying the logs due to its inability to contact the OCSP to complete the certificate revocation checks.
Diagnosis
-
less mp-log lcaas_agent.log
2018-08-27 15:16:47,108 lcaas_agent INFO Server-cert revocation check status: unavailable
This indicates that Panorama could not complete the certificate revocation checks.
2018-08-27 15:16:47,279 lcaas_agent INFO Resp from cloud service : [{"query":"8ad748e7-edbb-413a-b2c8-89c36750a859.api2-lc-prod-us.gpcloudservice.com:444","CustomerID":"117789002","region":"americas","region-display":"americas","ingest":"8ad748e7-edbb-413a-b2c8-89c36750a859.in2-lc-prod-us.gpcloudservice.com"}]
It is important to note that the above ‘Resp from cloud service’ does not necessarily mean that the service is responding to Panorama.
«request plugins cloud_services logging-service status» does not return any output and remains stuck until you kill the task using «CTRL+C»
- less mp-log plugin_cloud_services.log
2018-08-27 16:27:36.712 -0500 INFO: [update-device-cert] OCSP/CRL check status:
('unavailable', 'Output to be sent to /tmp/ocspoutput_911171761.data.nOCSP URL from the certificate http://ocsp.paloaltonetworks.com/ocsp.nOCSP cert status check is hosted atocsp.paloaltonetworks.com.nTrying connection to Host ocsp.paloaltonetworks.com for checking cert status.nError querying OCSP responsdern
2018-08-27 16:27:36.712 -0500 ERROR: [update-device-cert] No cert/key found. Probably trusted channel is not setup. Cannot continue.
You can see from the plugin_cloud_services.log that Panorama could not get a response from ocsp.paloaltonetworks.com where the OCSP cert status check is hosted due to a security rule on the edge firewall blocking access to this destination.
How was Panorama able to display the logs from the cloud service successfully before it stopped displaying them?
The reason is that at the time of onboarding logging-service, the user might have configured allow ‘any’ destination rule on the perimeter firewall and later modified the rule to allow granular access to Logging Service FQDNs only based on the Region(US or EU) from Panorama as source skipping the other destinations listed in the solution below:-
Resolution
Panorama needs to access these FQDNs for the initial setup and one-time password, and for ongoing certificate revocation checks.
- https://api.paloaltonetworks.com (TCP port 443)
- https://apitrusted.paloaltonetworks.com (TCP port 443)
- http://ocsp.paloaltonetworks.com/
Note:
For OCSP, you must also allow the firewalls to access ocsp.paloaltonetworks.com on port 80
- http://crl.paloaltonetworks.com/
- http://ocsp.godaddy.com/ (TCP port 80)
- *.gpcloudservice.com ( TCP port 444)
Open the security policy to Logging service to add the the above FQDNS as ‘Destination addresses’ and services(444, 443, 80)
These are listed in the following document as well and should be allowed access to before fine tuning the security policies for Panorama access to Logging Service (internet bound).
Cortex Data Lake Getting Started, TCP Ports and FQDNs Required for Cortex Data Lake
After successfully configuring the rule, Panorama should begin rendering logs and you can check connectivity to logging service using:
> request plugins cloud_services logging-service status
pass
{"@status": "success", "result": {"PODamericas": {"name": "americas", "Status": {"type": "status", "value": "OK", "tooltip": "OK"}, "@num_instances": 1, "Storage Us
ed (TB)": {"type": "number", "value": "0.516887", "limit": 1}, "Estimated Log Retention (Days)": 132, "entry": [{"name": "Americas", "Status": {"type": "status", "v
alue": "OK", "tooltip": "OK"}, "infra-audit-utilization": {"header": ["Infrastructure and Audit Logs", "Utilization"], "type": "number", "value": 1.94, "limit": 20.
48, "unit": "GB"}, "infra-audit-retention": {"header": ["Infrastructure and Audit Logs", "Retention"], "type": "number", "value": 151, "unit": "Days"}, "detail-util
ization": {"header": ["Detailed Logs", "Utilization"], "type": "number", "value": 509.06, "limit": 819.2, "unit": "GB"}, "detail-retention": {"header": ["Detailed L
ogs", "Retention"], "type": "number", "value": 132, "unit": "Days"}, "summary-utilization": {"header": ["Summary Logs", "Utilization"], "type": "number", "value": 1
8.29, "limit": 184.32, "unit": "GB"}, "summary-retention": {"header": ["Summary Logs", "Retention"], "type": "number", "value": 141, "unit": "Days"}, "@quota_info":
{"quota_details": "{"log-disk-quota":{"detailed":80,"infra-audit":2,"summary":18},"log-expiration-period":{"detailed":395,"infra-audit":395,"summary
":395},"min-retention-warning-period":{"detailed":14,"infra-audit":14,"summary":14},"@name":"americas","theater-quota":{"quota_count":1}}", "quota_
count": 1}}]}}}
See the certificate revocation status as follows in lcaas_agent.log
2018-08-27 15:25:47,108 lcaas_agent INFO Server-cert revocation check status: good
If the revocation status still shows ‘unavailable’, delete and re-fetch the Panorama-certificate using OTP.
Additional Information
For help to delete and re-fetch certificates on Panorama, please see The SSL certificate error» causing Panorama to not Display Logs from the logging-service»
Attachments
Am trying to set up OCSP validation routines, and so want to be comfortable with the environment first. Found excellent tutorials at for example OpenSSL: Manually verify a certificate against an OCSP.
Multiple questions arise, so please bear with me.
There have been some changes since that tutorial, but I think the gist is:
1) snag the certificate you want to verify, e.g.
openssl s_client -connect wikipedia.org:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > wikipedia.pem
2) build the certificate chain, e.g.
openssl s_client -connect wikipedia.org:443 -showcerts 2>&1 < /dev/null > chain.pem
and then edit appropriately. I found that the above doesn’t provide the self-signed CA certificate, GlobalSignRootCA, so added that in.
3) Determine the ocsp URI, e.g.
openssl x509 -noout -ocsp_uri -in wikipedia.pem
which returns
http://ocsp2.globalsign.com/gsorganizationvalsha2g2
4) Invoke the openssl ocsp client, e.g.
openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://ocsp2.globalsign.com/gsorganizationvalsha2g2
which returns
[woody@oc2042275410 testCerts]$ openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http ://ocsp2.globalsign.com/gsorganizationvalsha2g2
Error querying OCSP responsder
140062843348808:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:ocsp_ht.c:250:Code=403,Reason=Forbidden
(responsder?)
I read that this is due to a virtualization issue, so
openssl ocsp -issuer chain.pem -cert wikipedia.pem -url http://ocsp2.globalsign.com/gsorganizationvalsha2g2 -header "HOST" "ocsp2.globalsign.com"
which yields
Response Verify Failure
140400906352456:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:126:Verify error:unable to get local issuer certificate
wikipedia.pem: good
This Update: Apr 28 23:10:10 2015 GMT
Next Update: Apr 29 11:10:10 2015 GMT
So I’m getting that the OCSP returned that the cert is good, but this leads to question 1:
why the error ‘unable to get local issuer certificate’?
Ok, trying again with Google. Same routine, capturing cert, checking for OCSP URI:
openssl x509 -noout -ocsp_uri -in google.pem
yields
http://clients1.google.com/ocsp.
Fair enough:
openssl ocsp -issuer gchain.pem -cert google.pem -url http://clients1.google.com/ocsp
Error querying OCSP responsder
140433209165640:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:ocsp_ht.c:250:Code=404,Reason=Not Found
Not Found? That seemed surprising. Checking with wireshark:
> POST /ocsp HTTP/1.0
> Content-Type: application/ocsp-request
> Content-Length: 112
> 0n0l0E0C0A0...+..........j.....p.I.#z...(~d...U.. [.5...J:.......l..9.....{6.#0!0...+.....0......].O.9..}d`.L...
< ~HTTP/1.0 404 Not Found
< Content-Type: text/html; charset=UTF-8
< X-Content-Type-Options: nosniff
< Date: Tue, 28 Apr 2015 22:42:40 GMT
< Server: sffe
< Content-Length: 1429
< X-XSS-Protection: 1; mode=block
< Alternate-Protocol: 80:quic,p=1
<
< <!DOCTYPE html>
< <html lang=en>
< <meta charset=utf-8>
< <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
< <title>Error 404 (Not Found)!!1</title>
< <style>
< *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/errors/logo_sm_2.png) no-repeat}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/errors/logo_sm_2_hr.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/errors/logo_sm_2_hr.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/errors/logo_sm_2_hr.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:55px;width:150px}
< </style>
< <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
< <p><b>404.</b> <ins>That...s an error.</ins>
< <p>The requested URL <code>/ocsp</code> was not found on this server. <ins>That...s all we know.</ins>
So that is question 2: is this correct, the OCSP was moved, and isn’t present at the OCSP URI? Is it perhaps that the server has uniformly moved to OCSP stapling, and doesn’t consider the OCSP server important any longer?
- Remove From My Forums
-
Question
-
Currently, my I’m using a 2-tiered windows PKI with the offline standalone CA on windows 2012 servers. OCSP is being used to verify CA certificates. pkiview.exe gives no errors on the Enterprise CA.
An SSL cert has been issued on the Enterprise CA and then saved to a shared folder. this ocsp check is working fine from the server under associated AD. But its failing from other server both windows and Linux
—————- Certificate OCSP —————-
Unsuccessful «OCSP» Time: 0
[0.0] http://testserver.com/ocsp———————————
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
-url http://testserver.com/ocsp
Error querying OCSP responder
47287200207400:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:ocsp_ht.c:255:Code=404,Reason=Not Found
Answers
-
I would suspect firewall rules or something else are preventing machines other than the OCSP server from being able to reach port 80 to query OCSP.
Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder
of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com-
Proposed as answer by
Saturday, October 22, 2016 11:09 AM
-
Marked as answer by
Amy Wang_
Tuesday, November 1, 2016 12:51 PM
-
Proposed as answer by
-
As I mentioned, as long as the clients trust your root CA, which they would need to do anyway to use a Cert, they will trust your ocsp server. Domain has no bearing. Ocsp has no connection to AD or ldap.
Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder
of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com-
Proposed as answer by
Amy Wang_
Saturday, October 22, 2016 11:09 AM -
Marked as answer by
Amy Wang_
Tuesday, November 1, 2016 12:51 PM
-
Proposed as answer by
Edit June 19,2020: Added details to support OCSP request to servers that don’t support HTTP 1.0.
I had been working on understanding and troubleshooting an OCSP implementation and learnt a few things and thought I could share them on the blog.
What is OCSP?
Online Certificate Status Protocol (OCSP) defined in RFC 2560 is a protocol that:
enables applications to determine the (revocation) state of an identified certificate. OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs and may also be used to obtain additional status information. An OCSP client issues a status request to an OCSP responder and suspends acceptance of the certificate in question until the responder provides a response.
Basically, OCSP is a mechanism where a client can ask the CA if a certificate is valid. This method is better than Certificate Revocation List (CRL). In the CRL method, the CA publishes a list of all the certificates that it has issues and that has now been revoked. Instead of processing this whole bunch, the client can check the status of just one certificate with OCSP.
Here’s the steps of OCSP, as explained in the OCSP Stapling blog by Mozilla.
What is OCSP Stapling?
With OCSP, the client is responsible to make a call to the CA (OCSP responder) to verify the status of a server certificate. This can cause additional round-trip delays. So an alternate solution was designed where the server could help. When the client initiates the TLS hand-shake, the server can include the OCSP validation message along with its certificate. By “stapling” the verification information, the client can complete the hand-shake faster.
OCSP stapling was originally defined as Transport Layer Extension in RFC 6066. Specifically, the RFC calls out this functionality:
Allow TLS clients and servers to negotiate that the server sends the client certificate status information (e.g., an Online Certificate Status Protocol (OCSP) [RFC2560] response) during a TLS handshake. This functionality is desirable in order to avoid sending a Certificate Revocation List (CRL) over a constrained access network and therefore saving bandwidth.
Again, here’s the working of OCSP stapling from OCSP Stapling blog by Mozilla.
OCSP verification has been around for some time and OCSP stapling has been baked into the browsers for the past few years now. It is now gaining more widespread use as IoT devices are started to implement mutual authentication schemes.
Testing OCSP with Openssl
I had been working on an implementation that uses this OCSP Stapled response. The use case was that connected device makes a request to server over TLS. The device presents a client cert to authenticate itself to the server. The server verifies and then responds back with its certificate and the stapled OCSP response for the client to authenticate.
We ran into issues over the stapling and we had to verify the result. For this purpose, I am showing a request/response that does not include client certificates. This just makes the discussion a little bit simple.
To work on this aspect, I started to use Openssl and here’s the steps to achieve it:
Step 1: Get the server certificate
First, make a request to get the server certificate. When using openssl s_client -connect command, this is the stuff between the ------BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. I am using www.akamai.com as the server.
openssl s_client -connect www.akamai.com:443 < /dev/null 2>&1 | sed -n '/-----BEGIN/,/-----END/p' > certificate.pem
The server certificate is saved as certificate.pem.
Step 2: Get the intermediate certificate
Normally, a CA does not sign a certificate directly. They use intermediaries and we need to this make the openssl command work. So, make a request to get all the intermediaries.
To view the list of intermediate certs, use the following command.
openssl s_client -showcerts -connect www.akamai.com:443 < /dev/null 2>&1 | sed -n '/-----BEGIN/,/-----END/p'
The very first certificate is the server certificate we saved in step 2. For all the certificates below it, copy and save to a file named chain.pem.
Step 3: Get the OCSP responder for server certificate
The next step is to get the OCSP responder information. There are two ways to do this:
OCSP Responder with a command
We can use the server certificate certificate.pem and run a command to extract just the OCSP responder field:
$ openssl x509 -noout -ocsp_uri -in certificate.pem
http://ss.symcd.com
So here, http://ss.symcd.com is the OCSP responder.
OCSP Responder by examination
We can use the openssl command to print all the server certificate information using this command:
openssl x509 -text -noout -in certificate.pem
In the response, look for the section named Authority Information Access. This will hold the OCSP responder URL. In this case, here’s what I see:
Authority Information Access:
OCSP - URI:http://ss.symcd.com
CA Issuers - URI:http://ss.symcb.com/ss.crt
Step 4: Make the OCSP request
Now that we have the server certificate, CA certificate chain and the OCSP responder URL, we can make the actual verification call.
openssl ocsp -issuer chain.pem -cert certificate.pem -text -url http://ss.symcd.com
Here’s the relevant part of the response.
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: D1B1648B8C9F0DD16BA38ACD2B5017D5F9CFC064
Issuer Key Hash: 5F60CF619055DF8443148A602AB2F57AF44318EF
Serial Number: 7E34F9C3D2D21D999B668CC6C80EA4A8
Request Extensions:
OCSP Nonce:
0410AE9A77D9FBDE8F7EC1F0C3305183BAEC
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: A2117BB82AC97305A9CCC170F80F82442BBF509A
Produced At: Sep 12 16:58:10 2017 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: D1B1648B8C9F0DD16BA38ACD2B5017D5F9CFC064
Issuer Key Hash: 5F60CF619055DF8443148A602AB2F57AF44318EF
Serial Number: 7E34F9C3D2D21D999B668CC6C80EA4A8
Cert Status: good
This Update: Sep 12 16:58:10 2017 GMT
Next Update: Sep 19 16:58:10 2017 GMT
The most important part is the Cert Status: good line. This indicates that everything is kosher and the client can trust the certificate. The other part of interest is the details Next Update. This indicates the OCSP stapling response can be cached until the time so that we don’t overload the OCSP responder.
Handling newer OCSP validators
Many new OCPS validation endpoints like ocsp2.globalsign.com don’t support HTTP 1.0 requests. OCSP by default uses HTTP 1.0 which does not mandate the Host header. When this happens you may see a 400 error like this:
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 12EADF46CC0880387360B65A691601CC0CB5E9E2
Issuer Key Hash: A92B87E1CE24473B1BBFCF853702559D0D9458E6
Serial Number: 5625521AFA513B6D970FFAC1
Request Extensions:
OCSP Nonce:
0410C43AA490D8782F80C2D0751C417B6486
Error querying OCSP responder
4732960364:error:27FFF072:OCSP routines:CRYPTO_internal:server response error:/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.120.1/libressl-2.8/crypto/ocsp/ocsp_ht.c:251:Code=400,Reason=Bad Request
To fix this mismatch, we will need to add the Host header. This can be achieved by adding the option -header followed by the header information.
Here’s an example command:
openssl ocsp -issuer chain.pem -cert certificate.pem -text -url http://ocsp2.globalsign.com/cloudsslsha2g3 -header "HOST" "ocsp2.globalsign.com"
Thanks to Jim Carter’s explanation for helping identify and fix the issue.
Bonus: Dissecting OCSP request
I was curious to see on what actually happens during the OCSP request and ran a wireshark trace. When we make the OCSP request, this is submitted as a HTTP POST. In this case, the headers looked like this:
POST / HTTP/1.0
Content-Type: application/ocsp-request
Content-Length: 120
0v0t0M0K0I0 ..+..........d...
.k...+P.....d.._`.a.U..C..`*..z.C....~4.......f.......#0!0.. +.....0........w....~...0Q...
HTTP/1.0 200 OK
Server: nginx/1.10.2
Content-Type: application/ocsp-response
Content-Length: 1609
content-transfer-encoding: binary
Cache-Control: max-age=329052, public, no-transform, must-revalidate
Last-Modified: Tue, 12 Sep 2017 16:58:10 GMT
Expires: Tue, 19 Sep 2017 16:58:10 GMT
Date: Fri, 15 Sep 2017 21:33:58 GMT
Connection: close
If you notice, the “Cache-Control: max-age=329052” will be equal to the same as telling the client to cache the response until the Next Update time period. So the POST request can be cached.
Conclusion
OCSP request/response sounds a bit complex but, ultimately it is just HTTP request / response and can be tested with simple command line tools.