Technical Background Information
Some background information that isn't part of the ETEE-library but is still important to understand.
ETEE uses both certificates for signing and for encryption, in general these are 2 different certificates. For encrypting you require your own signing certificate and the others cryption certificate (for addressed) in the form of an ETK. For decypting you need
you own cryption certificate and authentication certificate (to verify your cryption certificate)
Currently it isn't possible to use your eID certificate for signing not only does the library currently lacks support for smart-carts the eID isn't conform to the requirements of the ETEE-library. There are plans to support this in the future.
Most likely you will need to use certificate that are issued by eHealth see
. eHealth will deliver a Government certificate that conforms to the requirements and can be used to sign the messages. eHealth also has a tool available that allows you to generate
an cryption certificate and register it with the ETK-Depot. Localy both certificates and there private keys are stored in p12 file.
Theoretically it is possible to use signing certificates of other authorities to seal a message as long as they are conform to the requirements. In reality other signing certificates should only be used if the receiving party is explicitly supporting/requiring
it. To my knowledge there aren't such cases (yet).
For the rest of this section we assume you are in possession of an eHealth p12 file with both singing and cryption certificate.
There are 2 ways of selecting a certificate and its private key in .Net: from PKCS#12 (p12) file and from Windows X509 Store.
From PKCS#12 file
You can open a p12 file via the
constructor, but there are some pitfalls:
- .Net does not fully support p12 files with more then 1 private key which the eHealth p12 file is.
- The library requires the private keys to be exportable, don't forget to specify the correct option in the constructor
So, if you want to use p12 files you need to split up the eHealth p12 files into 2 separate p12 files, there are several way to do this:
From Windows X509 Store
The eHealth p12 file can be easily imported into the Windows 509 Store by double clicking on it and follows the wizard. Make sure you flag the private keys as exportable.
.Net has a
class that can be used to access the certificates from the Windows X509 Store.
The .Net ETEE-library uses the standard certificate revocation mechanism of the .Net framework. On windows this means the revocation mechanism of the operating system.
By default Windows does only support CRL revocation. Normally this isn’t an issue, most certificates (including the ones from eHealth) contain the required information to do CRL revocation test. There is a risk that there CRLs grow large (the largest eID CRL
is 24 MB) which is far from ideal.
Alternatively you can add OCSP support to Windows by installing the PKIF/ OCSP Plug-in (see
). When the certificate supports it, Windows will do an OCSP check before it will try a CRL check. OCSP is an online protocol that validates a single certificate
If the standard Windows revocation and or the OCSP Plug-in aren’t sufficient you can always add your own revocation provider(s) in Windows. Details on how to create such custom revocation provider is out of scope for this document, but a good starting point
can be http://msdn.microsoft.com/en-us/library/ms995348