Downloads of untrusted certificates from the production service

[louridas]

Your Question

We are running version 0.5 of dgca-verifier-service.

When the service runs, it downloads 85 certificates from the production infrastructure:

2021-06-16 14:25:59.720  INFO 6 --- [   scheduling-3] e.e.e.d.g.c.DgcGatewayDownloadConnector  : Got Response from DGCG, Downloaded Certificates: 85

However, it then reports that there are 38 trusted certificates:

2021-06-16 14:26:00.576  INFO 6 --- [   scheduling-3] e.e.e.d.g.c.DgcGatewayDownloadConnector  : DSC TrustStore contains 38 trusted certificates.

That means, among other things, that we cannot use DSCs from Germany and Lithuania.

• Is there something wrong with these certificates, and is this the expected behaviour?
• When does the verifier service not trust a certificate?
• Under what circumstances a DSC that has been uploaded to production is untrusted?
• Shouldn’t these untrusted certificates be pulled out (cleared) from the production service in the first place?

Best Regards,

Panos.

[slaurenz]

Hi Panos,

Thanks for your report.

As you noted you use the version 0.5.0 of the verifier-service. This version uses an old version of the dgc-lib (v0.4.3) for downloading and checking the certificates. The download handling got updated in the dgc-lib scince this version.

Please update to the current released version of the verifier-service (v 1.0.3) and retest the download from the prod gateway.

If the behavior doesn't change, don't hisitate to ask again.

Best Regards
Simon

[louridas]

Hello,

We updated to the latest version and now we download and accept 91 certificates, so indeed that was the reason. Thanks!

Now, every time we sync (every minute), we get a log with about 300 lines explaining that the certificates are checked. Could you explain what a line like:

021-06-18 09:41:47.152 DEBUG 6 --- [   scheduling-1] e.e.e.d.g.c.DgcGatewayConnectorUtils     : Could not verify that certificate was issued by ca. Certificate: C=DE,O=Robert Koch-Institut,OU=Elektronischer Impfnachweis,CN=Robert Koch-Institut,L=Berlin,PostalCode=13353,STREET=Nordufer 20,organizationIdentifier=DT:DE-3023531445,SERIALNUMBER=CSM026460099,ST=Berlin, CA: C=SI,O=NIJZ\, National Institute of Public Health of Slovenia,OU=NIJZ eHealth,CN=Slovenian Digital Covid Certificate CSCA

means? That the DSC is not issued by an approved CSCA? If yes, how has it been uploaded? Or does it mean something else?

Best Regards,

Panos.

[louridas]

We had a thread on Slack (#eu-digital-green-certificates-dev) and Ján Jančár (https://github.com/J08nY) came with the answer:

The log is made at DgcGatewayConnectorUtils.java#L65 in the method trustListItemSignedByCa which is supposed to check whether a given DSC is signed by a given CA, which is the important part. Now that method is called at DgcGatewayDownloadConnector#208 where it is called in a greedy loop over all CSCA certificates. This means that it will print those logs until it gets to a CSCA certificate that is the correct issuer of the DSC. So this is not an issue with the certificates, more like an issue of a too verbose logging call. Also, I am not sure why the Issuer of the DSC is not used to figure out which CSCA to use to validate the signature on the DSC.

This indeed raises then the question, why not use the Issuer on the DSC to narrow down the list of potential matches?

[f11h]

Hi @louridas ,

In general you are right - it would make sense to previously search for a possible matching CSCA and then validate it. I've created an Issue in the dgc-lib project to put this topic on our backlog. But as long as it is only a performance improvement this will have a low priority.

eu-digital-green-certificates/dgc-lib#46

Regarding the log output. The detailed information when validating a CSCA is in DEBUG-Level. Maybe you can check your logger settings.