Certificate Problems in MVDS scenario

[Haifischbecken]

Hi everyone,

I am trying to setup the IDS-testbed as a MVDS for exploration and testing. I tried running the docker compose with the default settings and while all the containers start up I can not reach the connectors.

curl -i localhost:8080 (no TLS) returns

HTTP/1.1 400 
Content-Type: text/plain;charset=UTF-8
Connection: close

Bad Request
This combination of host and port requires TLS.

Trying with TLS yields curl: (60) SSL certificate problem: unhandled critical extension

This led me to looking at the certificates used and trying to verfiy the certifactes with openssl points at the the same problem

input: ~/IDS-testbed/CertificateAuthority$ openssl verify --CAfile ./data/ca/ReferenceTestbedCA.crt --untrusted ./data/subca/ReferenceTestbedSubCA.crt ./data/cert/testbed1.crt

output:

C = ES, O = SQS, OU = TestLab, CN = testbed1
error 34 at 0 depth lookup: unhandled critical extension
C = ES, O = SQS, OU = TestLab, CN = ReferenceTestbedSubCA
error 34 at 1 depth lookup: unhandled critical extension
C = ES, O = SQS, OU = TestLab, CN = ReferenceTestbedCA
error 34 at 2 depth lookup: unhandled critical extension
error ./data/cert/testbed1.crt: verification failed

After some trial and error I found that neither subjectKeyIdentifier and authorityKeyIdentifier can be critical for openssl to verify them, which they are in the provided certifcates and the ones generated by pki.py. At least for subjectKeyIdentifier this is also backed by rfc3280

4.2.1.2 Subject Key Identifier ... This extension MUST NOT be marked critical.

I have not come around to running the MVDS with the altered certificates, but will try to do so next.

I am not an expert on the topic, so if there is a specific reason why these extensions need to be marked critical please let me know. Also if there might be a different fix to the problem I would also be happy to hear about it.

Cheers

[jfernandezsqs]

Hi @Haifischbecken,

At the following closed issue there is an explanation that could clarify the error you are encountering. Please, take a look at https://github.com/International-Data-Spaces-Association/IDS-testbed/issues/131#issuecomment-1727173149

For your information, currently, there is an ongoing pull request that uses certificates generated with CFSSL. This is IDS-testbed pull request CA: changing to CFSSL as CA with OCSP support. This will use different certificates and with this, it should not appear your mentioned error.

[Haifischbecken]

Hi @jfernandezsqs

I finally found time to look into this again. There already was an entry for localhost in the host file which looks like this.

127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

So this did not seem to be the issue. Is there a reason why this would cause openssl to not verify the vertificates even though it was provided the full chain including the CA certifacte to be trusted?