The data sheet of HSM is mention , that you have a preinstalled root CA from CardContact.
with sc-hsm-tool -X ( what should be the first step ) it will delete alle files, certificates and keys.
So is the CA root hard coded ?
(Can’t check it as the pkcs11-engine for openssl is not build under FreeBSD)
Yes, it’s hard-coded.
Thanks - Then I will try to generate it under a Linux-Distri or try to find the bug, why it is not build on FreeBSD 
Hmm, is there a cmd to list the preinstalled root CA from CardContact ? a pksc15-tool -D shows only my UserPin and the SecurityOfficer Pin.
I do not know unfortunately. Maybe the SCSH could help you in that case?
Device authentication uses a CVC-based PKI with a Scheme Root CA (SRCA), several Device Issuer CAs and a device certificate that binds the SmartCard-HSM’s unique id with the device authentication key.
The SRCA (DESRCACC100001) is an offline CA operated by CardContact. The certificate is usually fixed as trust-anchor in the client, like in OpenSC [1].
The certificate is also written as trust-anchor in the SmartCard-HSM during production. This trust-anchor is used by the device for Public Key Authentication and other peer authentication mechanisms like authenticated ECDH and key domain based key distribution.
Ok, in short: I need to create a certificate and then I will see a trust anchor, but it will be a self-signed certificate - correct ?
Ahhh nope…
The Root CA certificate (DESRCACC100001) is not exposed at the interface. It’s just stored internally during production and can be used to verify Device Issuer CA certificates.
You could extract the Device Issuer certificate from your device and pass that to the (same or other) device in the PSO:VERIFY CERTIFICATE command. The SmartCard-HSM would then validate the Device Issuer certificate and make it’s public key internally available. In a subsequent step you could use your device certificate and have that validated with the same command. Ultimately the SmartCard-HSM would trust a public key generated on a different device, based on the full chain of certificates from the public key to the SRCA (Remember, freshly generated key pairs get their public key signed by the device authentication key (in TR-03110 CSR format). Via the chain CSR, Device Certificate, Device Issuer CA Certificate, Scheme Root CA Certificate you can prove authenticity of a key pair generated on a SmartCard-HSM. That mechanism is for example used in the PKI-as-a-Service Portal to authenticate public keys when CDN certificates are issued.
A good example that shows the process is available in the agreeKey.js example available at the CDN. In that example two EC keys are generated and their authenticity is validated by a peer SmartCard-HSM in order to agree a common secret. The mechanism has been developed in a customer project to agree shared keys in an encrypted communication using SRTP. Both peers in that setup authenticate each other based on CV-certificate exchanged during communication setup.
