Hallo Peter,
vielen Dank für die schnelle Antwort.
Das mit dem Truecrypt-Container halte ich für eine gute Idee. Ich habe sogar schon gehört, dass Root CAs auf virtuellen Servern auf externen Laufwerken installiert werden und die Laufwerke anschließend im Tresor landen. Man kann nie paranoid genug sein. (Wobei das anerkennend gemeint ist. Man kann ja viel Blödsinn mit einer geklauten CA anstellen). Wir verwenden jedoch zuhause eine Windows Domäne und versuchen immer in neue Bereiche vorzudringen, die sich damit verwalten lassen.
Aber zurück zum Thema:
Ich vermute, dass du in den Attributen der Userzertifikate einen Fehler gemacht hast. Diese Vermutung resultiert daraus, dass du die Benutzerzertifikate nicht unter "Personen", aber dafür unter "Server" installieren kannst. Es sieht so aus, dass in diesen Zertifikaten die falschen capabilities (also SSL-Client oder -Server usw., und nicht alle Optionen für E-Mail = Digital Signature, Key Encipherment, Data Encipherment, und E-mail Protection) eingetragen wurden.
Das ist auch meine Vermutung. Daher habe ich versucht den Fehler durch das ausprobieren verschiedener Attribute zu reproduzieren und kann auch folgendem nur zustimmen:
Der Fehler muss also irgendwo im Detail liegen.
Nur sind diese Details leider (noch) nicht meine Stärke.
Was du auch wissen musst ist, dass du bei einem unter "Personen" importierten Userzertifikat nicht noch einmal das Vertrauen aussprechen darfst! Also nur importieren und fertig. Wenn du das Vertrauen einstellst, verschwindet das Zertifikat aus "Personen" und taucht auf einmal unter "Server" auf! Das Vertrauen der Userzertifikate wird automatisch von den als vertrauenswürdig deklarierten Herausgeberzertifikaten geerbt.
Ich wünschte, ich wäre so weit gekommen, diesen Fehler machen zu können. Aber leider ist der Import an sich gescheitert. Aber das ist schon mal gut zu wissen, für die Zeit, wenn es funktioniert.
Da ich jemand bin, der nicht viel Zeit für Foren hat, möchte ich diesen Fall öffentlich für die Nachwelt dokumentieren. Daher folgen nun die XCA Konfigurationen der verschiedenen Zertifikate (Details des Zertifikates anzeigen >> Erweiterungen >> Konfiguration anzeigen), die ich wieder aus Datenschutzgründen zensiert habe. Überall dort wo das geschehen ist, wurde der Text durch ein Tag in "spitzen Klammern" (<>) ersetzt.
Ich habe mich für diese Darstellungsform entschieden, da ich festgestellt habe, dass es bei den meisten Programmen am einfachsten ist, wenn man eine schöne Key-Value-Tabelle der Konfiguration hat, um Fehler zu finden. Insbesondere war "Linux" in deinem Beitrag da ein Schlüsselwort für mich. Da das jedoch nicht immer gilt - es kommt ja immer darauf an, was man gewohnt und wie das Programm ist - zögere bitte nicht, mich um eine andere Darstellungsform zu bitten. Ich persönlich finde da immer die Windows-Zertifikatsdarstellung gut, da sie sehr sprechend ist.
Windows Zertifizierungsstelle
Root CA (Windows Zertifizierungsstelle):
MsCaV=DER:02:01:00
subjectKeyIdentifier=hash
basicConstraints=critical,CA:TRUE
keyUsage=digitalSignature, keyCertSign, cRLSign
Sub CA (Windows Zertifizierungsstelle):
authorityInfoAccess=caIssuers;URI:<Eine URL>
crlDistributionPoints=crlDistributionPoint0_sect
authorityKeyIdentifier=keyid
basicConstraints=critical,CA:TRUE
keyUsage=digitalSignature, keyCertSign, cRLSign
dom=DER:1e:0a:00:53:00:75:00:62:00:43:00:41
subjectKeyIdentifier=hash
MsCaV=DER:02:01:00
[crlDistributionPoint0_sect]
fullname=URI:<Eine URL>
Alles anzeigen
E-Mail-Zertifikat (Windows Zertifizierungsstelle):
SMIME-CAPS=DER:30:35:30:0e:06:08:2a:86:48:86:f7:0d:03:02:02:02:00:80:30:0e:06:08:2a:86:48:86:f7:0d:03:04:02:02:00:80:30:07:06:05:2b:0e:03:02:07:30:0a:06:08:2a:86:48:86:f7:0d:03:07
1.3.6.1.4.1.311.21.10=DER:30:0c:30:0a:06:08:2b:06:01:05:05:07:03:04
extendedKeyUsage=emailProtection
1.3.6.1.4.1.311.21.7=DER:<ID des Templates>
keyUsage=critical,digitalSignature, keyEncipherment
authorityInfoAccess=caIssuers;URI:<Eine URL>, caIssuers;URI:<Eine URL>
crlDistributionPoints=crlDistributionPoint0_sect
authorityKeyIdentifier=keyid
subjectKeyIdentifier=hash
[crlDistributionPoint0_sect]
fullname=URI:<Eine URL>, URI:<Eine URL>
Alles anzeigen
Der Signaturalgorithmus ist bei der Windows Zertifizierungsstelle jeweils rsassaPss.
XCA
Root CA Test (XCA):
Sub CA Test (XCA):
nsComment=xca certificate
nsCertType=sslCA, emailCA, objCA
keyUsage=keyCertSign, cRLSign
subjectKeyIdentifier=hash
basicConstraints=critical,CA:TRUE
E-Mail-Zertifikat (XCA):
authorityInfoAccess=caIssuers;URI:<Eine URL>, caIssuers;URI:<Eine URL>
1.3.6.1.4.1.311.21.7=DER:<ID des Templates>
1.3.6.1.4.1.311.21.10=DER:30:0c:30:0a:06:08:2b:06:01:05:05:07:03:04
SMIME-CAPS=DER:30:35:30:0e:06:08:2a:86:48:86:f7:0d:03:02:02:02:00:80:30:0e:06:08:2a:86:48:86:f7:0d:03:04:02:02:00:80:30:07:06:05:2b:0e:03:02:07:30:0a:06:08:2a:86:48:86:f7:0d:03:07
crlDistributionPoints=crlDistributionPoint0_sect, crlDistributionPoint1_sect
extendedKeyUsage=emailProtection
keyUsage=critical,digitalSignature, keyEncipherment
authorityKeyIdentifier=keyid, issuer
subjectKeyIdentifier=hash
[crlDistributionPoint1_sect]
fullname=URI:<Eine URL>
[crlDistributionPoint0_sect]
fullname=URI:<Eine URL>
Alles anzeigen
Der Signaturalgorithmus ist bei XCA jeweils sha256WithRSAEncryption.
S/MIME-Attribute
Die "SMIME-CAPS" müssten aufgelöst folgendes ergeben (so findet es sich in der schon erwähnten Windows-Zertifikatsdarstellung:
[1]SMIME-Funktion
Objekt-ID=1.2.840.113549.3.2
Parameter=02 02 00 80
[2]SMIME-Funktion
Objekt-ID=1.2.840.113549.3.4
Parameter=02 02 00 80
[3]SMIME-Funktion
Objekt-ID=1.3.14.3.2.7
[4]SMIME-Funktion
Objekt-ID=1.2.840.113549.3.7
Mit Gruß,
hat_guy