search

International-Data-Spaces-Association / IDS-testbed

Apache License 2.0
24 stars 32 forks source link

CA: changing to CFSSL as CA with OCSP support #129

Closed mokamhuber closed 6 months ago

jfernandezsqs commented 1 year ago

Hello @mokamhuber,

I have reviewed the PR and I have made some changes to correctly create the certificate in PEM format. Later it is required to generate the appropriate p12, cert and crt certificates, so that they can be used at the respective IDS-testbed component.

I have some doubts with the certificates and the OCSP:

First, the process to request the OCSP for the status of a specific certificate.

It is not detailed at the certificate where to request or perform that request. For example, I do not know how to check or how to verify if connectorA receives a request from connectorB the information from the OCSP.

To check the status of the certificate (good or revoked) I perform the following request:

openssl ocsp -issuer ocsp/ocsp_components.pem -issuer subca/subca.pem -no_nonce -cert certs/connectorA.pem -CAfile subca/subca.pem -text -url http://localhost:8888

However, these request is using the .pem certificate and I can perform it because I have total access to the OCSP server.

mokamhuber commented 1 year ago

Hi Josu, the format and content of the requests is defined in RFC 6960 (https://www.rfc-editor.org/rfc/rfc6960). The only challenge is that one needs to know the endpoint that this requests needs to be sent to. That information should be provided via the respective extension of the certificate (but we still need to check if it is correctly included in the current implementation)

JackyXiangcheng commented 1 year ago

Hi, could we change the self-signed ca certificate(ReferenceTestbedCA.crt) to a trusted ca certificate, so that we can access the domain url from google browser safely?

mokamhuber commented 11 months ago

I did an analysis of the script today and found some issues that prevented the OCSP URL from being added to the x509 certificate, this should have been fixed now by the previous commit

jfernandezsqs commented 10 months ago

Hello @mokamhuber

I have provided some feedback to your pull request. I have updated the IDS-testbed documentation InstallationGuide.md. I have updated the CertificateAuthority folder with the following points:

Please, take a look at my changes. If neccessary I am available for a meeting where we can see the changes and possible modifications. Additionally, we can use this meeting to close the pull request and update the IDS-testbed version accordingly.

PabloArdoiz commented 9 months ago

I have tested the new CA and everything seems to be working as it is expected. It is possible to establish communication between all the components and no error logs have been encountered in the terminal. The information about the OCSP implementation is complete.

jfernandezsqs commented 7 months ago

Hello @mokamhuber, I have just made the changes commented on today's meeting, which are the following:

Additionally, I wanted to clarify the following point: If the OCSP server is launched at port 8888 and it is requested any connector it says the following. Requested connectorB status of revocation:

openssl ocsp -issuer ocsp/ocsp_components.pem -issuer subca/subca.pem -no_nonce -cert certs/connectorB.pem -CAfile subca/subca.pem -text -url http://localhost:8888

Logs obtained at the OCSP server:

2024/01/16 16:21:42 [DEBUG] Received OCSP request: MFUwUzBRME8wTTAJBgUrDgMCGgUABBQJacLAKDAA9yqF2MVmI5PPsrfKOAQUxHbQqs2TeTUP66dkYJCka7Q4TTMCFCmG5mm8rTavXzwpiegQP2Bm0q2s

2024/01/16 16:21:42 [DEBUG] Received request: {"ip":"127.0.0.1:34324","method":"POST","path":"/","body":"MFUwUzBRME8wTTAJBgUrDgMCGgUABBQJacLAKDAA9yqF2MVmI5PPsrfKOAQUxHbQqs2TeTUP66dkYJCka7Q4TTMCFCmG5mm8rTavXzwpiegQP2Bm0q2s","received":"2024-01-16T16:21:42.297362279+01:00","took":2901352,"headers":{"Cache-Control":["max-age=340697, public, no-transform, must-revalidate"],"Content-Type":["application/ocsp-response"],"Etag":["\"CBCC9914BCD04A85A77F76EF1AFA35FC8C8CB68DC1649DFF039432C47E5ADC49\""],"Expires":["Sat, 20 Jan 2024 14:00:00 UTC"],"Last-Modified":["Tue, 16 Jan 2024 14:00:00 UTC"]},"serial":"2986e669bcad36af5f3c2989e8103f6066d2adac","issuerKeyHash":"c476d0aacd9379350feba7646090a46bb4384d33","issuerNameHash":"0969c2c0283000f72a85d8c5662393cfb2b7ca38","hashAlg":"SHA1"}

There it is detailed that the certificate expires at: "Expires":["Sat, 20 Jan 2024 14:00:00 UTC"] For executions of TCSs and verifications of connector's implementations it would be desirable to be greater this expiration time. Is it possible to configure this expiration time?

mokamhuber commented 7 months ago

Hi @jfernandezsqs thanks for updating it. The changes look alright for me. Regarding your question: The validity period of the OCSP response should be configurable using the option "-interval 96h" for the ocsprefresh command. However, for the testbed I would suggest that we simply execute the "cfssl ocsprefresh" and "cfssl ocspdump" command before executing "cfssl ocspserve". This way we always generate the list of OCSP responses freshly before the respective test cases (based on the stored database) and the default validity of 96h should suffice for the current test run.