![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.gif){kind=icon}
PKI (Deel 2)
Ok, in PKI (Deel 1) hebben we een eerste kennismaking gehad met de principes van PKI, en hebben we de certificaten vluchtig bekeken.
In dit volgende deel gaan we de certificaten verder bespreken, kijken we naar de verschillende typen en kijken we naar hun geldigheid.
In deel 1 meldde ik reeds dat een certificaat gemaakt wordt van een CSR (Certificate Signing Request). Hoe een CSR is opgebouwd gaan we nu bekijken.
Wanneer ik een nieuw certificaat ga aanvragen, maak ik gebruik van een bestaande sleutelset of maak ik een nieuwe sleutelset. (Hoe dit aanmaken van een nieuw certificaat verloopt kom ik later op terug.) Uiteindelijk krijg ik een PEM Encoded (Privacy Enhanced Mail == Base64 Encoded ASCII) tekstbestand met bijvoorbeeld de volgende inhoud.
let op: Dit is test data
code:
Geloof het of niet, maar dit stukje text bevat mijn 1024 bits publieke sleutel en nog veel meer informatie. Deze is uit te lezen met behulp van OpenSSL, wat de volgende output levert:
code:
Laten we hier de belangrijke zaken uitlichten.
code:
Dit is het onderwerp van het certificaat. Ook wel de "Distinguished Name" of kortweg DN genoemd. Dit bevat enkele waardes die voor mijn persoon van toepassing zijn. Het bestaat uit enkele DN velden die vrij invulbaar zijn.
code:
Het sleutelpaar is gebaseerd op RSA (zie deel 1)
code:
De Publieke Sleutel is 1024 bits groot.
code:
De nu volgende data is de publieke sleutel.
Deze CSR wordt via mail of een andere manier verstuurd naar de Certificerings Instantie (CA) die de waarden op waarheid zal controleren. Hoe deze controle verloopt ligt buiten de scope van dit blog, maar ga er maar vanuit dat je bij de bekendere CA's geen certificaat kan krijgen als je geen teogang hebt tot het e-mail account wat je hebt opgegeven bij het aanmaken van het CSR.
Als de controle positief is verlopen, krijg je het certificaat terug. Meestal in het PEM formaat, maar het kan ook in het DER (Distinguished Encoding Rules == Een binair bestand) formaat zijn.
Wanneer we naar een voorbeeld bestand kijken.. Dit is een PEM encoded 2048bits groot certificaat.
code:
Bekijken we deze met OpenSSL:
code:
Je ziet enkele gelijkheden met het CSR hierboven. Er zijn echter wat belangrijke toevoegingen bijgekomen.
code:
Dit is inweze het subject of het DN van de CA. In dit geval toevallig het zelfde als het subject van dit certificaat wat betekend dat het een zogeheten "self-signed"-certificaat is.
Wanneer je de root-certificaten (het hoogste certificaat in de keten) van een willekeurige CA bekijkt, zal dit altijd een self-signed certificaat zijn. Is een beetje een kip-ei verhaal
code:
Dit houd in dat het certificaat 3 jaar geldig is.
code:
Dit is wat lastiger, maar laat ik het zo stellen. X509 is een standaard voor digitale certificaten. Dit deel bevat alle v3 extensions.
code:
Het certificaat is een CA certificaat. Bij andere certificaten zal hier FALSE staan.
Welke verschillende typen certificaten zijn er
In het kopje KeyUsage onder de X509v3 Extensions staat een bit string van mogelijkheden. Deze mogelijkheden zijn:
0 digitalSignature => Digitaal ondertekenen, anders dan nonRepudiation
1 nonRepudiation => Onweerlegbaarheid. Ondertekenen van vb. E-Mail
2 keyEncipherment => Gebruik voor veilige sleutel overdracht (SSL)
3 dataEncipherment => Gebruik voor Data versleuteling zijnde geen cryptografische sleutels
4 keyAgreement => Gebruik bij overleg sleutelmateriaal.
5 keyCertSign => Ondertekenen van Certificaten (CA only)
6 cRLSign => Ondertekenen van CRL's (Certificate Revocation List)
7 encipherOnly => Versleutelen van data; alleen in combinatie met (4)
8 decipherOnly => Ontsleutelen van data; alleen in combinatie met (4)
Vaak kan je kiezen uit verschillende sjablonen welke 1 of enkele KeyUsage velden gebruiken.
Zie hoofdstuk 4.2.1.3 (Key Usage) in Internet X.509 Public Key Infrastructure voor gedetailleerde uitleg.
Geldigheid: CRL of OCSP
Een certificaat heeft een bepaalde geldigheidsduur. Voor deze tijd is hij niet geldig, en na deze tijd is hij niet geldig.
Nu kan het echter zijn dat een bepaald certificaat direct ingetrokken moet worden. Een uitgevende CA kan een certificaat ook weer intrekken, waardoor hij niet meer gebruikt kan worden.
Wanneer een certificaat ingetrokken wordt, komt zijn serienummer op een lijst van ingetrokken certificaten. Dit is de zogeheten CRL (Certificate Revocation List)
Wanneer een certificaat dan gecontroleerd wordt op zijn geldigheid (Bijvoorbeeld iemand krijgt een ondertekende E-Mail binnen welke is ondertekend met het ingetrokken certificaat) zal de lezer van deze E-mail een melding krijgen dat het certificaat niet geldig meer is. De mail kan nog wel worden gelezen, maar het zou kunnen zijn dat de versturende partij niet meer mag spreken uit naam van een bedrijf o.i.d.
Deze CRL is een file welke ergens publiek bereikbaar geplaatst moet worden. Een CRL wordt op gezette tijden gegenereerd, en kan dus enige tijd achterlopen op de werkelijkheid.
Er is een directer systeem, welke op ieder moment van de dag de geldigheid van een certificaat kan testen, en altijd een valide resultaat teruggeeft. Dit is OCSP. (Online Certificate Status Protocol). Ook dit systeem vereist een life verbinding, maar werkt sneller en is accurater. Bovendien hoeft de client ( de ontvanger van de E-Mail) niet een volledige CRL - die na enige tijd best groot kan worden - te downloaden om deze door te worstelen.
Voor de betrouwbaarheid van de OCSP response, word deze Digitaal ondertekend om de onweerlegbaarheid te garanderen.
Tot zover weer Deel 2 van deze PKI kennismaking. Tips, vragen en of ideeën voor deel 3 zijn welkom
In dit volgende deel gaan we de certificaten verder bespreken, kijken we naar de verschillende typen en kijken we naar hun geldigheid.
In deel 1 meldde ik reeds dat een certificaat gemaakt wordt van een CSR (Certificate Signing Request). Hoe een CSR is opgebouwd gaan we nu bekijken.
Wanneer ik een nieuw certificaat ga aanvragen, maak ik gebruik van een bestaande sleutelset of maak ik een nieuwe sleutelset. (Hoe dit aanmaken van een nieuw certificaat verloopt kom ik later op terug.) Uiteindelijk krijg ik een PEM Encoded (Privacy Enhanced Mail == Base64 Encoded ASCII) tekstbestand met bijvoorbeeld de volgende inhoud.
let op: Dit is test data
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| -----BEGIN CERTIFICATE REQUEST----- MIIB8jCCAVsCAQAwgbExCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1CcmFi YW50MQ4wDAYDVQQHEwVCcmVkYTEhMB8GA1UEChMYSW50ZXJuZXQgV2lkZ2l0cyBQ dHkgTHRkMSAwHgYDVQQLExdCZWhlZXIgZW4gT25kZXJzdGV1bmluZzEQMA4GA1UE AxMHRXF1YXRvcjEjMCEGCSqGSIb3DQEJARYURXF1YXRvckBUd2Vha2Vycy5uZXQw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALWoq5avUdL8mDyORsbs3gZRN5rx VuNRuvUgPU3KHEk6X6f9u62UrHGxiR+bKZKQU/hLG7eaSW7ZYe5D+Ib1O0jnztKp a9+0/6TCZ4iJcMiYBWcpwAGmxc+/X3XDf8Ea42JRBrNUxM+0htVqwvCsjrR6v0Xq soz0N25yVFhqzi3ZAgMBAAGgADANBgkqhkiG9w0BAQUFAAOBgQBzlEvpxFOtYpbM e+t94mj8xCxYlyf67FhRjyuQornDc7IhmWOcMRWsA36W3MFhHVOxMo9HAdku3Zyg pSlli7OFDn+F6+T8B+YpkcFXbS3bzmWPMbzpaPd9DnZp4+J6nXCQVfBg4hX554vr CQ2xlHF9UJ6HDB9kvXJ6rM7hPVAdIg== -----END CERTIFICATE REQUEST----- |
Geloof het of niet, maar dit stukje text bevat mijn 1024 bits publieke sleutel en nog veel meer informatie. Deze is uit te lezen met behulp van OpenSSL, wat de volgende output levert:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| OpenSSL> req -in test.csr -noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=NL, ST=Noord-Brabant, L=Breda, O=Internet Widgits Pty Ltd, OU=Beheer en Ondersteuning, CN=Equator/emailAddress=Equator@Tweakers.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b5:a8:ab:96:af:51:d2:fc:98:3c:8e:46:c6:ec:
de:06:51:37:9a:f1:56:e3:51:ba:f5:20:3d:4d:ca:
1c:49:3a:5f:a7:fd:bb:ad:94:ac:71:b1:89:1f:9b:
29:92:90:53:f8:4b:1b:b7:9a:49:6e:d9:61:ee:43:
f8:86:f5:3b:48:e7:ce:d2:a9:6b:df:b4:ff:a4:c2:
67:88:89:70:c8:98:05:67:29:c0:01:a6:c5:cf:bf:
5f:75:c3:7f:c1:1a:e3:62:51:06:b3:54:c4:cf:b4:
86:d5:6a:c2:f0:ac:8e:b4:7a:bf:45:ea:b2:8c:f4:
37:6e:72:54:58:6a:ce:2d:d9
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha1WithRSAEncryption
73:94:4b:e9:c4:53:ad:62:96:cc:7b:eb:7d:e2:68:fc:c4:2c:
58:97:27:fa:ec:58:51:8f:2b:90:a2:b9:c3:73:b2:21:99:63:
9c:31:15:ac:03:7e:96:dc:c1:61:1d:53:b1:32:8f:47:01:d9:
2e:dd:9c:a0:a5:29:65:8b:b3:85:0e:7f:85:eb:e4:fc:07:e6:
29:91:c1:57:6d:2d:db:ce:65:8f:31:bc:e9:68:f7:7d:0e:76:
69:e3:e2:7a:9d:70:90:55:f0:60:e2:15:f9:e7:8b:eb:09:0d:
b1:94:71:7d:50:9e:87:0c:1f:64:bd:72:7a:ac:ce:e1:3d:50:
1d:22
OpenSSL> |
Laten we hier de belangrijke zaken uitlichten.
code:
1
| Subject: C=NL, ST=Noord-Brabant, L=Breda, O=Internet Widgits Pty Ltd, OU=Beheer en Ondersteuning, CN=Equator/emailAddress=Equator@Tweakers.net |
Dit is het onderwerp van het certificaat. Ook wel de "Distinguished Name" of kortweg DN genoemd. Dit bevat enkele waardes die voor mijn persoon van toepassing zijn. Het bestaat uit enkele DN velden die vrij invulbaar zijn.
- C => Countrycode (Landcode)
- ST => State (Provincie)
- L => Locality Name (Woonplaats)
- O => Organisation Name
- OU => Organisational Unit (Afdeling in de organisatie)
- CN => Common Name (De naam van de gebruiker zoals hij bekend is)
code:
1
| Public Key Algorithm: rsaEncryption |
Het sleutelpaar is gebaseerd op RSA (zie deel 1)
code:
1
| RSA Public Key: (1024 bit) |
De Publieke Sleutel is 1024 bits groot.
code:
1
| Modulus (1024 bit): |
De nu volgende data is de publieke sleutel.
Deze CSR wordt via mail of een andere manier verstuurd naar de Certificerings Instantie (CA) die de waarden op waarheid zal controleren. Hoe deze controle verloopt ligt buiten de scope van dit blog, maar ga er maar vanuit dat je bij de bekendere CA's geen certificaat kan krijgen als je geen teogang hebt tot het e-mail account wat je hebt opgegeven bij het aanmaken van het CSR.
Als de controle positief is verlopen, krijg je het certificaat terug. Meestal in het PEM formaat, maar het kan ook in het DER (Distinguished Encoding Rules == Een binair bestand) formaat zijn.
Wanneer we naar een voorbeeld bestand kijken.. Dit is een PEM encoded 2048bits groot certificaat.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| -----BEGIN CERTIFICATE----- MIIEPDCCAySgAwIBAgIJAKrYA72HsVW/MA0GCSqGSIb3DQEBBQUAMHExCzAJBgNV BAYTAk5MMRAwDgYDVQQIEwdVdHJlY2h0MQ4wDAYDVQQHEwVPZGlqazEeMBwGA1UE ChMVdnRzIFBvbGl0aWUgTmVkZXJsYW5kMQ0wCwYDVQQLFARJViZUMREwDwYDVQQD EwhJbmZyYSBXSTAeFw0wNzEyMTQxMjMzMjZaFw0xMDA5MTAxMjMzMjZaMHExCzAJ BgNVBAYTAk5MMRAwDgYDVQQIEwdVdHJlY2h0MQ4wDAYDVQQHEwVPZGlqazEeMBwG A1UEChMVdnRzIFBvbGl0aWUgTmVkZXJsYW5kMQ0wCwYDVQQLFARJViZUMREwDwYD VQQDEwhJbmZyYSBXSTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKO/ +++++++ 5 regels verwijderd ++++++ gTFp3LNc6AN8tZ9R+ZECAwEAAaOB1jCB0zAdBgNVHQ4EFgQUhe+GSRH0dkmlKasd NSAVdp2n5QwwgaMGA1UdIwSBmzCBmIAUhe+GSRH0dkmlKasdNSAVdp2n5QyhdaRz MHExCzAJBgNVBAYTAk5MMRAwDgYDVQQIEwdVdHJlY2h0MQ4wDAYDVQQHEwVPZGlq azEeMBwGA1UEChMVdnRzIFBvbGl0aWUgTmVkZXJsYW5kMQ0wCwYDVQQLFARJViZU MREwDwYDVQQDEwhJbmZyYSBXSYIJAKrYA72HsVW/MAwGA1UdEwQFMAMBAf8wDQYJ KoZIhvcNAQEFBQADggEBAKHRnccLOPjxAhd9JOfaXgn0HYoC4tlwfaTeyEUhGytQ u43Sc7x3zaBLmm/YV8ikAbt7VhwWZIxpT0TDQWAchWp/TyHsyj0tyFGI59XBKB1k zCC7d/VUOA/ZJtisx4zK4mKeMbEMo9bufGTEjpjHd9IpU8dU2138RSdCEMaZteON xg8nrpkoLA0wwU1sO91qv5mv9ZxuQ+XfbK5dwW8k7yWm+ypik2MnFb3JHEtlGwBe xQOmV9w23gkHrHjHcq/T9ozbgOcEV3b2mvn61rgh4+lnQ+H+HZTF9nfRKXc/lzAX njrBaeYn5ZJxSz0iAmRuHu1jfpBm2om7+RQXhrq5cnY= -----END CERTIFICATE----- |
Bekijken we deze met OpenSSL:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
| OpenSSL> x509 -in ca.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
aa:d8:03:bd:87:b1:55:bf
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=NL, ST=Noord-Brabant, L=Breda, O=Test Organisatie, OU=Ontwikkeling, CN=Mijn CA
Validity
Not Before: Dec 14 12:33:26 2007 GMT
Not After : Sep 10 12:33:26 2010 GMT
Subject: C=NL, ST=Noord-Brabant, L=Breda, O=Test Organisatie, OU=Ontwikkeling, CN=Mijn CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:a3:bf:46:58:2d:f0:60:90:12:cb:33:06:02:e2:
12:02:e4:38:65:d9:09:1f:16:24:79:53:11:1a:6c:
48:52:68:8f:03:b2:f2:03:5c:6d:31:3d:32:62:23:
7d:77:3a:1f:ca:06:7a:15:7d:dd:dd:b4:39:69:0a:
6f:b9:1d:e2:0a:3c:f5:05:b2:70:62:9c:d4:52:70:
5e:ba:44:29:09:99:fa:2e:08:06:48:36:7a:07:c9:
6b:8a:63:e2:e5:ca:06:34:7d:22:36:4c:8e:1c:46:
13:06:dc:40:2c:fd:94:08:f5:9e:bd:7b:86:bc:ea:
8f:ae:f4:87:6a:f3:42:fb:99:42:b4:62:8c:b7:ff:
fc:c0:bf:29:e0:a2:cd:b9:18:b1:3d:f9:5a:61:01:
1c:c0:a8:26:a9:3d:d9:f6:aa:a4:64:87:1c:40:fc:
7c:b5:ad:89:71:30:77:52:3c:33:36:03:8f:5d:13:
2e:33:e6:31:a4:b7:18:b8:5f:59:f4:88:0b:bc:ca:
ab:71:83:7c:0c:64:de:f5:1a:13:42:49:4d:5c:d6:
fe:77:dc:74:85:ea:38:bf:fb:be:a2:dd:76:3b:1d:
4d:66:cc:25:fb:dd:d9:91:76:12:1e:8d:4c:bf:f4:
6f:1b:a4:81:31:69:dc:b3:5c:e8:03:7c:b5:9f:51:
f9:91
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
85:EF:86:49:11:F4:76:49:A5:29:AB:1D:35:20:15:76:9D:A7:E5:0C
X509v3 Authority Key Identifier:
keyid:85:EF:86:49:11:F4:76:49:A5:29:AB:1D:35:20:15:76:9D:A7:E5:0C
DirName:/C=NL/ST=Noord-Brabant/L=Breda/O=Test Organisatie/OU=Ontwikkeling/CN=Mijn CA
serial:AA:D8:03:BD:87:B1:55:BF
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
a1:d1:9d:c7:0b:38:f8:f1:02:17:7d:24:e7:da:5e:09:f4:1d:
8a:02:e2:d9:70:7d:a4:de:c8:45:21:1b:2b:50:bb:8d:d2:73:
bc:77:cd:a0:4b:9a:6f:d8:57:c8:a4:01:bb:7b:56:1c:16:64:
8c:69:4f:44:c3:41:60:1c:85:6a:7f:4f:21:ec:ca:3d:2d:c8:
51:88:e7:d5:c1:28:1d:64:cc:20:bb:77:f5:54:38:0f:d9:26:
d8:ac:c7:8c:ca:e2:62:9e:31:b1:0c:a3:d6:ee:7c:64:c4:8e:
98:c7:77:d2:29:53:c7:54:db:5d:fc:45:27:42:10:c6:99:b5:
e3:8d:c6:0f:27:ae:99:28:2c:0d:30:c1:4d:6c:3b:dd:6a:bf:
99:af:f5:9c:6e:43:e5:df:6c:ae:5d:c1:6f:24:ef:25:a6:fb:
2a:62:93:63:27:15:bd:c9:1c:4b:65:1b:00:5e:c5:03:a6:57:
dc:36:de:09:07:ac:78:c7:72:af:d3:f6:8c:db:80:e7:04:57:
76:f6:9a:f9:fa:d6:b8:21:e3:e9:67:43:e1:fe:1d:94:c5:f6:
77:d1:29:77:3f:97:30:17:9e:3a:c1:69:e6:27:e5:92:71:4b:
3d:22:02:64:6e:1e:ed:63:7e:90:66:da:89:bb:f9:14:17:86:
ba:b9:72:76
OpenSSL> |
Je ziet enkele gelijkheden met het CSR hierboven. Er zijn echter wat belangrijke toevoegingen bijgekomen.
code:
1
| Issuer: C=NL, ST=Noord-Brabant, L=Breda, O=Test Organisatie, OU=Ontwikkeling, CN=Mijn CA |
Dit is inweze het subject of het DN van de CA. In dit geval toevallig het zelfde als het subject van dit certificaat wat betekend dat het een zogeheten "self-signed"-certificaat is.
Wanneer je de root-certificaten (het hoogste certificaat in de keten) van een willekeurige CA bekijkt, zal dit altijd een self-signed certificaat zijn. Is een beetje een kip-ei verhaal
code:
1
2
3
| Validity
Not Before: Dec 14 12:33:26 2007 GMT
Not After : Sep 10 12:33:26 2010 GMT |
Dit houd in dat het certificaat 3 jaar geldig is.
code:
1
| X509v3 extensions: |
code:
1
2
| X509v3 Basic Constraints:
CA:TRUE |
Het certificaat is een CA certificaat. Bij andere certificaten zal hier FALSE staan.
Welke verschillende typen certificaten zijn er
In het kopje KeyUsage onder de X509v3 Extensions staat een bit string van mogelijkheden. Deze mogelijkheden zijn:
0 digitalSignature => Digitaal ondertekenen, anders dan nonRepudiation
1 nonRepudiation => Onweerlegbaarheid. Ondertekenen van vb. E-Mail
2 keyEncipherment => Gebruik voor veilige sleutel overdracht (SSL)
3 dataEncipherment => Gebruik voor Data versleuteling zijnde geen cryptografische sleutels
4 keyAgreement => Gebruik bij overleg sleutelmateriaal.
5 keyCertSign => Ondertekenen van Certificaten (CA only)
6 cRLSign => Ondertekenen van CRL's (Certificate Revocation List)
7 encipherOnly => Versleutelen van data; alleen in combinatie met (4)
8 decipherOnly => Ontsleutelen van data; alleen in combinatie met (4)
Vaak kan je kiezen uit verschillende sjablonen welke 1 of enkele KeyUsage velden gebruiken.
Zie hoofdstuk 4.2.1.3 (Key Usage) in Internet X.509 Public Key Infrastructure voor gedetailleerde uitleg.
Geldigheid: CRL of OCSP
Een certificaat heeft een bepaalde geldigheidsduur. Voor deze tijd is hij niet geldig, en na deze tijd is hij niet geldig.
Nu kan het echter zijn dat een bepaald certificaat direct ingetrokken moet worden. Een uitgevende CA kan een certificaat ook weer intrekken, waardoor hij niet meer gebruikt kan worden.
Wanneer een certificaat ingetrokken wordt, komt zijn serienummer op een lijst van ingetrokken certificaten. Dit is de zogeheten CRL (Certificate Revocation List)
Wanneer een certificaat dan gecontroleerd wordt op zijn geldigheid (Bijvoorbeeld iemand krijgt een ondertekende E-Mail binnen welke is ondertekend met het ingetrokken certificaat) zal de lezer van deze E-mail een melding krijgen dat het certificaat niet geldig meer is. De mail kan nog wel worden gelezen, maar het zou kunnen zijn dat de versturende partij niet meer mag spreken uit naam van een bedrijf o.i.d.
Deze CRL is een file welke ergens publiek bereikbaar geplaatst moet worden. Een CRL wordt op gezette tijden gegenereerd, en kan dus enige tijd achterlopen op de werkelijkheid.
Er is een directer systeem, welke op ieder moment van de dag de geldigheid van een certificaat kan testen, en altijd een valide resultaat teruggeeft. Dit is OCSP. (Online Certificate Status Protocol). Ook dit systeem vereist een life verbinding, maar werkt sneller en is accurater. Bovendien hoeft de client ( de ontvanger van de E-Mail) niet een volledige CRL - die na enige tijd best groot kan worden - te downloaden om deze door te worstelen.
Voor de betrouwbaarheid van de OCSP response, word deze Digitaal ondertekend om de onweerlegbaarheid te garanderen.
Tot zover weer Deel 2 van deze PKI kennismaking. Tips, vragen en of ideeën voor deel 3 zijn welkom
 06-03
|
PKI in the Enterprise |
 11-12
|
PKI (Deel 1) |
Reacties
Door
froggie,
donderdag 28 februari 2008 13:16
Wellicht wat te ver, maar ik ben op zoek naar informatie/een goed voorbeeld van een LDAP based PKI, waarmee ik certificaten kan uitgeven voor VPN verbindingen, interne services etc. Het gaat hierbij meer om de grote lijnen zoals welke certificaten gegenereerd moeten worden, in welke structuur ik die kan opslaan, hoe om te gaan met een CLR, dan om een stap voor stap handleiding.
Door
Equator,
vrijdag 07 maart 2008 09:52
@Froggie,
Ik zie je reactie nu pas, maar bij deze:
Als ik lees waar je naar op zoek bent kan ik je het beste aanraden om gewoon een Microsoft Enterprise CA te installeren. (Het liefste nog op een WIndows 2003 Enterprise Server omdat je dan flexibeler bent met het gebruik van eigen certificate templates)
Een Enterprise CA is AD integrated, en de standaard User certificaten zijn prima geschikt om VPN clients mee te laten werken. (tenzij je aparte dingen nodig hebt)
Ik wil tzt een keer een blog posten over het invoeren van een Ent. CA in een AD omgeving voor diverse zaken.
Ik zie je reactie nu pas, maar bij deze:
Als ik lees waar je naar op zoek bent kan ik je het beste aanraden om gewoon een Microsoft Enterprise CA te installeren. (Het liefste nog op een WIndows 2003 Enterprise Server omdat je dan flexibeler bent met het gebruik van eigen certificate templates)
Een Enterprise CA is AD integrated, en de standaard User certificaten zijn prima geschikt om VPN clients mee te laten werken. (tenzij je aparte dingen nodig hebt)
Ik wil tzt een keer een blog posten over het invoeren van een Ent. CA in een AD omgeving voor diverse zaken.
Om te kunnen reageren moet je ingelogd zijn. Via deze link kun je inloggen als je al geregistreerd bent. Indien je nog geen account hebt kun je er hier één aanmaken.