[[TOC(heading=OpenAC3, sectionindex, compact, depth=3, allactive, Documentatie/Ontwikkelaar/OpenAC3/)]]
[[TOC(heading=Omgeving, sectionindex, compact, depth=3, allactive, Documentatie/Ontwikkelaar/Omgeving/)]]
[[TOC(heading=Procedures, sectionindex, compact, depth=3, allactive, Documentatie/Ontwikkelaar/Procedures/)]]
[[TOC(heading=Documentatie, sectionindex, compact, depth=1, allactive, Documentatie/)]]

= FENAC !ZorgDomein SSL Inrichting =

Dit document beschrijft hoe de FENAC de communicatie tussen OpenAC 3 Server
(decentraal, bij de AC's zelf -- dat zijn de zorgverleners) en OpenACHub
(centraal, bij de FENAC -- dat is de tussen-postbus voor !ZorgDomein-verkeer)
beveligd is en welke procedures gehanteerd worden.

Algemeen geldt dat de clients (dwz. OpenAC 3 Server) controleren dat de
server (dwz. OpenACHub) ge-identificeerd wordt door het juiste certificaat,
en aan de server-kant wordt gecontroleerd dat (a) de client een geldig certificaat
aanbiedt en (b) de client, ge-identificeerd door het certificaat, de uitvraag
mag doen in de request (dwz. mag het client certificaat wel verwijzingen opvragen
voor de aangegeven AGB code).

Revisies:
 - 0.1 dd 20170105 initieel document


== SSL Chain of Trust ==

Voor de !ZorgDomein koppeling heeft de FENAC een eigen, self-signed, CA key
gemaakt. Gedurende de test-fase wordt geen extra aandacht besteed aan de
beveiliging van de host waarop de CA key en intermediate certificates opgeslagen
worden (dwz. het is een werkstation ten burele van de FENAC). Aangezien deze root-CA alleen gebruikt wordt voor het verstrekken van de intermediate voor de !ZorgDomein-koppeling wordt dit niet als een zwaarwegend probleem gezien.

=== CA Aanmaken ===

FENAC maakt gebruik van het standaard OpenSSL helper-script CA.pl om de CA root
en intermediate certificates te genereren.

 - CA root: `CA.pl -newca`
   - In te voeren gegevens voor deze CA root zijn:
     {{{
        Subject:
            countryName               = NL
            stateOrProvinceName       = Utrecht
            organizationName          = FENAC UA
            commonName                = fenac.nl
            emailAddress              = info@fenac.nl
}}}
   - De key die in de test-fase wordt gebruikt, heeft deze fingerprints:
     {{{
         X509v3 extensions:
            X509v3 Subject Key Identifier:
                C9:D7:1C:4B:E3:23:9A:A3:FA:66:41:40:55:FC:68:5B:DB:D4:19:0C
            X509v3 Authority Key Identifier:
                keyid:C9:D7:1C:4B:E3:23:9A:A3:FA:66:41:40:55:FC:68:5B:DB:D4:19:0C
}}}
 - Intermediate: `CA.pl -newreq ; CA.pl -signCA`
   - In te voeren gegevens voor deze intermediate zijn (m.n. andere CN):
     {{{
        Subject:
            countryName               = NL
            stateOrProvinceName       = Utrecht
            localityName              = Utrecht
            organizationName          = FENAC UA
            organizationalUnitName    = ZorgDomein Koppeling
            commonName                = zd.fenac.nl
            emailAddress              = info@fenac.nl
}}}
   - De key die in de test-fase wordt gebruikt, heeft deze fingerprints:
     {{{
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                7F:6C:AF:8A:77:48:33:6E:4E:29:E9:F3:79:A0:8B:A2:6C:A6:CD:09
            X509v3 Authority Key Identifier:
                keyid:C9:D7:1C:4B:E3:23:9A:A3:FA:66:41:40:55:FC:68:5B:DB:D4:19:0C
}}}
 - Intermediate opslaan in demoCA directory:
   - `mv newcert.pem demoCA/intermediatecert.pem`
   - `mv newkey.pem demoCA/private/intermediatecert.pem`
 - Certificate chain maken:
   - `cat demoCA/intermediatecert.pem  demoCA/cacert.pem > demoCA/fenaczd-chain-cert.pem`


### Client Certificates

Gedurende de test-fase worden client-certificates door de FENAC zelf uitgegeven
(zoals VECOZO en het UZI register ook doen). Er wordt niet gewerkt als een
traditionele CA met binnenkomende sign-requests. Gedurende de test-fase wordt
geen extra aandacht besteed aan de beveiliging van de host waarop de client-
certificates worden opgeslagen. Gedurende de test-fase wordt geen extra aandacht
besteed aan de manier waarop de client-certificates getransporteerd worden
naar de clients (dwz. naar de AC's waar ze de certificaten installeren in hun
OpenAC 3 Server).

 - Request aanmaken: `CA.pl -newreq-nodes`
   - Als test hebben we een certificaat voor AC Utrecht gemaakt. Aanbevolen
     in om `OU=ZorgDomein Koppeling` te gebruiken, en voor CN het domein van
     de instelling (ic. acutrecht.nl) zonder subdomeinen.
 - Request signen (met de intermediate!): 
   {{{
openssl ca  -policy policy_anything \
   -cert demoCA/intermediatecert.pem -keyfile demoCA/private/intermediatecert.pem \
   -out newcert.pem -infiles newreq.pem
}}}
 - Certificate opslaan in demoCA directory. Dit gebeurt automatisch (met de
   serial / hash) voor het getekend certificaat. Gedurende de test-fase worden de
   private-keys ook opgeslagen in de demoCA, onder de naam van de aanvrager:
   - `mv newkey.pem demoCA/private/ac_utrecht.pem`
 - Certificate omzetten naar PKCS!#12 voor gebruik door Windows / OpenAC 3 Server (hier met de hashcode van het nieuwe certificaat): 
   {{{
openssl pkcs12 -export -out ac_utrecht.pfx  \
  -in newcerts/F1633F593C632CE2.pem \
  -inkey private/ac_utrecht.pem \
  -certfile fenaczd-chain-cert.pem
}}}