Open eCard build on Raspbian Buster fails due to invalid certificate
Added by Burkhard Austermühl almost 5 years ago
On a Raspberry 4 with Raspbian Buster, I have generated a Java / Maven environment as required in the Open eCard Github INSTALL.md file: Java OpenJDK 13, Maven 3.6.3
~/Git/open-ecard $ mvn -version Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) Maven home: /opt/maven Java version: 13.0.1, vendor: AdoptOpenJDK, runtime: /usr/lib/jvm/adoptopenjdk-13-hotspot-armhf Default locale: de_DE, platform encoding: UTF-8 OS name: "linux", version: "4.19.97-v7l+", arch: "arm", family: "unix"
Maven successfully generates a number of components, then fails on the Open eCard Common Libs. Further generation step are then skipped:
Reactor Summary for Open eCard Client 2.1.0-SNAPSHOT: [INFO] [INFO] Open eCard Client .................................. SUCCESS [01:01 min] [INFO] Src-Parent ......................................... SUCCESS [ 2.234 s] [INFO] Open eCard Webservice Definitions .................. SUCCESS [ 0.083 s] [INFO] Open eCard WS common ............................... SUCCESS [ 26.250 s] [INFO] Open eCard WS classes .............................. SUCCESS [01:24 min] [INFO] JAXB Marshaller .................................... SUCCESS [ 28.641 s] [INFO] Open eCard I18n .................................... SUCCESS [ 0.812 s] [INFO] Open eCard Common Libs ............................. FAILURE [ 1.663 s] [INFO] GUI implementations ................................ SKIPPED ...
Maven error message is as follows:
[ERROR] Failed to execute goal on project common: Could not resolve dependencies for project org.openecard:common:jar:2.1.0-SNAPSHOT: Failed to collect dependencies at org.openecard:bcprov-jdk15on:jar:1.62: Failed to read artifact descriptor for org.openecard:bcprov-jdk15on:jar:1.62: Could not transfer artifact org.openecard:bcprov-jdk15on:pom:1.62 from/to openecard-repos (https://mvn.ecsec.de/repository/openecard-public): Transfer failed for https://mvn.ecsec.de/repository/openecard-public/org/openecard/bcprov-jdk15on/1.62/bcprov-jdk15on-1.62.pom: Invalid CertificateVerify signature -> [Help 1]
The link to [Help 1] says:
Dependency Resolution Exception
This error generally occurs when Maven could not download dependencies. Possible causes for this error are:
The POM misses the declaration of the <repository> which hosts the artifact.
The repository you have configured requires authentication and Maven failed to provide the correct credentials to the server. In this case, make sure your ${user.home}/.m2/settings.xml contains a <server> declaration whose <id> matches the <id> of the remote repository to use. See the Maven Settings Reference for more details.
The remote repository in question uses SSL and the JVM running Maven does not trust the certificate of the server.
There is a general network problem that prevents Maven from accessing any remote repository, e.g. a missing proxy configuration.
You have configured Maven to perform strict checksum validation and the files to download got corrupted.
Maven failed to save the files to your local repository, see LocalRepositoryNotAccessibleException for more details.
It seems that the Open eCard repository requires some certificate which my Maven installation does not provide. Is there such requirement, and if yes, which?
Replies (8)
RE: Open eCard build on Raspbian Buster fails due to invalid certificate - Added by Tobias Wich over 4 years ago
I just checked and the artifact is available when opened in a browser. The certificate is from Let's Encrypt. Normally their CA cert should be present in the java truststore, but maybe you can check that. The CN of their root is "ISRG Root X1" or "Let's Encrypt Authority X3" if you want to look for the intermediate cert.
RE: Open eCard build on Raspbian Buster fails due to invalid certificate - Added by Burkhard Austermühl over 4 years ago
The java truststore provided with the AdoptOpenJDK (the only post-version 11 JDK I managed to run on Raspbian Buster) seems to contain an old (04.06.2015) entry for the Let's Encrypt CA:
letsencryptisrgx1 [jdk], 04.06.2015, trustedCertEntry, Zertifikat-Fingerprint (SHA-256): 96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6
The default-java truststore seems to contain the required CA entry:
debian:isrg_root_x1.pem, 26.09.2019, trustedCertEntry, Zertifikat-Fingerprint (SHA-256): 96:BC:EC:06:26:49:76:F3:74:60:77:9A:CF:28:C5:A7:CF:E8:A3:C0:AA:E1:1A:8F:FC:EE:05:C0:BD:DF:08:C6
The certificate fingerprint is the same, but the CA identification is different. Let's see whether I can import
RE: Open eCard build on Raspbian Buster fails due to invalid certificate - Added by Tobias Wich over 4 years ago
I don't think that the alias in the truststore is relevant. However the fingerprint is different than what the used certificates are.
Here is the chain of the server (SHA-256):
host: A8:A2:6B:90:4E:EB:69:F8:33:24:5E:FE:2F:F8:92:A7:4C:A4:E4:51:1C:73:0C:FD:6C:4B:7B:3A:5A:63:59:EB
let's encrypt X3: 25:84:7D:66:8E:B4:F0:4F:DD:40:B1:2B:6B:07:40:C5:67:DA:7D:02:43:08:EB:6C:2C:96:FE:41:D9:DE:21:8D
dstroot: 06:87:26:03:31:A7:24:03:D9:09:F1:05:E6:9B:CF:0D:32:E1:BD:24:93:FF:C6:D9:20:6D:11:BC:D6:77:07:39
The picture here calrifies whats going on. https://letsencrypt.org/certificates/
Obviously they switched the root cert that they deliver in certbot and this one is not in your keystore. The certificates for importing are also available there.
RE: Open eCard build on Raspbian Buster fails due to invalid certificate - Added by Burkhard Austermühl over 4 years ago
OUTDATED
Keytool -list -v on the two cacerts files shows identical entries for the Let's Encrypt CA except for the alias names and the generation date (Erstellungsdatum). Validity of the certificate is until 04.06.2035. I would therefore assume that the needed certificate is present, and that the Maven problem is a different one.
RE: Open eCard build on Raspbian Buster fails due to invalid certificate - Added by Tobias Wich over 4 years ago
To make it clear. If you don't find a certificate with the following fingerprint in your truststore you will have to import DST Root CA X3.
06:87:26:03:31:A7:24:03:D9:09:F1:05:E6:9B:CF:0D:32:E1:BD:24:93:FF:C6:D9:20:6D:11:BC:D6:77:07:39
RE: Open eCard build on Raspbian Buster fails due to invalid certificate - Added by Burkhard Austermühl over 4 years ago
The let's encrypt X3 and dstroot certificates with the quoted fingerprints are now in $JAVA_HOME/lib/security/cacerts. The Maven error when building :common nevertheless remains the same. Seems that Maven does not follow the CA certificate chain, but needs the public key of the host
RE: Open eCard build on Raspbian Buster fails due to invalid certificate - Added by Tobias Wich over 4 years ago
I searched for the exact error message and the only thing I found was the java source code.
https://hg.openjdk.java.net/jdk/jdk11/rev/68fa3d4026ea#l22.648
If that is indeed the code that prints the message, then the signature in the TLS CertificateVerify message does not match the public key of the server certificate. I have seen such problems with Antivirus proxy software corrupting the TLS messages, but that is probably not the case on a raspi.
There are three things in use with this server that have been known to cause trouble in the past. TLS 1.3, SNI and EC certificates. A look at a tcpdump capture might reveal if any of those things is a problem here.
RE: Open eCard build on Raspbian Buster fails due to invalid certificate - Added by Burkhard Austermühl over 4 years ago
tcpdump und Wireshark sind mehr etwas zu heavy für meinen Versuch, die Open eCard auf dem raspi zum Laufen zu bringen. Ich habe versucht, anders an mehr Informationen zu kommen, und gesehen, dass die von Maven/Java nicht ladbare XML-Datei bcprov-jdk15on-1.62.pom (die man im Browser ganz normal anschauen kann) einen sonderbaren Eintrag enthält:
<outputDirectory> /home/neil/_/projects/open-ecard/openecard-bouncycastle/bc-java/build/mybc </outputDirectory>
Den user neil gibt es bei mir natürlich nicht. Da ich mich mit Maven und .pom-Dateien nicht auskenne, weiß ich nicht, ob das eine Bedeutung hat. Jedenfalls ist die Komponente :common die erste, in der diese Direktive auftritt. Die vorherigen, erfolgreich gebauten Komponenten enthalten so etwas nicht.