Tehdyt toimenpiteet

Varmenne FAQ

1. Minulla on varmenne ja siihen yksityinen avain, kuinka saan nämä keystoreen, jotta voin käyttää samaa varmennetta myös Tomcatissa tai AAIEyessä?

Helpoin keino on käyttää AAIEye:n bin -hakemistosta löytyvää importkey.sh -skriptiä. Muokkaa sen alkuun asennuksesi mukaiset polut ja aja skripti, se luo uuden keystoren, joka sisältää varmenteen ja yksityisen avaimen.

Myös Shibboleth 1:en mukana tullut extkeytool -työkalu osaa saman asian.

Toinen tapa on kikkailla keytool:in ja openssl:n kanssa. Huom: tarvitset Java 6:n tähän keinoon! Lihavoidut kohdat on muutettava oman ympäristösi mukaisiksi. Ensin luodaan tilapäinen PKCS12-muotoinen keystore, jonka voi poistaa operaation lopuksi. Kirjoita koko komento yhdelle riville:

openssl pkcs12 -export -inkey privatekey.pem -in certificate.pem 
 -CAfile soneraclass2.ca.pem -out keystore.pkcs12 -name "alias"

Sitten tämä keystore konvertoidaan Javan keystore -muotoon:

keytool -importkeystore -srckeystore keystore.pkcs12 -destkeystore keystore.jks 
 -srcstoretype PKCS12 -srcstorepass keystoresalasana -deststorepass keystoresalasana 
 -deststoretype JKS -srcalias alias -destalias alias -srckeypass varmennesalasana 
 -destkeypass varmennesalasana -noprompt

2. Minulla on varmenteen yksityinen avain Javan keystoressa, ja haluaisin käyttää sitä myös WWW-palvelimessa. Miten saan avaimen ulos keystoresta ja Apachen ymmärtämään muotoon?

Tämä ei onnistu suoraan Javan keytool:in optioilla, vaan vaatii pientä temppuilua. Huom: tarvitset Java 6:n tähän keinoon! Ensiksi luodaan uusi PKCS12-muotoinen keystore (keystore.p12) olemassaolevasta keystoresta (keystore.jks). Lihavoidut kohdat on muutettava oman ympäristösi mukaisiksi. Kirjoita koko komento yhdelle riville.

keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 
 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass keystoresalasana 
 -deststorepass keystoresalasana -srcalias alias 
 -destalias alias -srckeypass varmennesalasana -destkeypass varmennesalasana -noprompt

Sitten käyttäen openssl:ää kaivetaan yksityinen avain tästä luodusta keystoresta.

openssl pkcs12 -in keystore.p12 -out keystore.pem 
 -passin pass:keystoresalasana -passout pass:keystoresalasana

openssl rsa -in keystore.pem > privatekey.pem

Lopuksi voit poistaa syntyneet tilapäiset keystore.p12 ja keystore.pem -tiedostot.

3. Miten varmistan, että varmenteessani on SSL Client -ominaisuus, jota tarvitaan SP:ssä attribuuttikyselyiden tekemisessä?

SSL Client -tuki vaaditaan Service Provider:in varmenteelta, jotta sitä voidaan käyttää attribuuttikyselyiden tekemiseksi lähinnä 1.3 IdP:iden kanssa.

Valmiista varmenteesta asian voi tarkistaa openssl:llä:

openssl x509 -in varmenne.pem -purpose

Vastauksessa pitäisi olla:

Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No

Jos tässä kohta 'SSL client' sanoo 'No', on varmenne luotava uudestaan asian korjaamiseksi. Etsi openssl:n konfiguraatiotiedostosta (Redhat EL4:ssa /usr/share/ssl/openssl.cnf) kohta 'nsCertType', ja kommentoi se kokonaan pois tai lisää siihen 'client'. Huom! Soneran varmenteiden tilauslomakkessa on nykyisin kohta "Palvelinvarmenne, jossa client-bitti", joka pitää myös olla ruksattuna.

4. SP:ni/IdP:ni varmenne on vanhentumassa, miten toimin?

Tässä ohjeessa on kerrottu toimintaohjeet Hakaan rekisteröityjen palveluiden varmenteen uusimiseksi esimerkiksi varmenteen vanhentuessa tai avaimen tai varmenteen vaihtuessa muusta syystä. Seuraamalla ohjetta tarkasti voidaan varmenteen vaihto tehdä ilman merkittäviä palvelukatkoja. Mikäli varmenne täytyy vaihtaa tietoturvasyistä, tätä ohjetta ei tule noudattaa vaan varmenne on vaihdettava välittömästi, ota tällöin yhteyttä CSC:n Haka-ylläpitoon.

Huom: tässä ohjeessa kerrotaan varmenteen vaihdosta vain Shibbolethin ja Haka-metadatan suhteen. Muista lisäksi uusia vaihtunut varmenne Tomcatistä / www-palvelimesta.

Varmenteen vaihtaminen (Service Provider)

Konfiguroi SP:si käyttämään rinnakkain sekä uutta että vanhaa varmennetta siten, että vanha varmenne on ensimmäisenä eli oletuksena käytössä. Esimerkki shibboleth2.xml:stä:

<CredentialResolver type="Chaining">
  <CredentialResolver type="File">
    <Key>
      <Name>VanhaAvain</Name>
      <Path>/etc/shibboleth/vanha.key</Path>
    </Key>
    <Certificate>
      <Path>/etc/shibboleth/vanha.crt</Path>
    </Certificate>
  </CredentialResolver>
  <CredentialResolver type="File">
    <Key>
      <Name>UusiAvain</Name>
      <Path>/etc/shibboleth/uusi.key</Path>
    </Key>
    <Certificate>
      <Path>/etc/shibboleth/uusi.crt</Path>
    </Certificate>
  </CredentialResolver>
</CredentialResolver>

Lisää Resurssirekisterissä SP:si rekisteröintitietoihin uusi varmenne vanhan lisäksi. Metadataan päätyvät tällöin molemmat varmenteet. Mikäli sinulla ei ole Haka-tunnuksia, lähetä uusi varmenne sähköpostitse haka@csc.fi
Odota, että metadata julkaistaan ja että se ehtii päivittyä IdP:ihin. Tämän jälkeen vaihda SP:si konfiguraatiossa varmenteiden järjestystä siten, että uusi varmenne on ensimmäisenä ja tulee siis oletukseksi (ks. kohta 1 - eli vaihdat tässä näiden CredentialResolver:eiden järjestyksen päinvastaiseksi. Huom. Ensimmäisenä listassa olevan varmenteen on oltava voimassa! Eli tämä kohta on syytä ehtiä tekemään ennen kuin vanha varmenne vanhenee.
Nyt voit poistaa vanhan varmenteen metadatasta Resurssirekisterillä.
Kun metadata on jälleen päivittynyt, voit poistaa SP:si konfiguraatiosta vanhan varmenteen.

Varmenteen vaihtaminen (Identity Provider)

Lisää Resurssirekisterissä IdP:si rekisteröintitietoihin uusi varmenne vanhan lisäksi. Metadataan päätyvät tällöin molemmat varmenteet. Mikäli sinulla ei ole Haka-tunnuksia, lähetä uusi varmenne sähköpostitse haka@csc.fi
Odota, että metadata julkaistaan ja että se ehtii päivittyä SP:ihin. Tämän jälkeen vaihda IdP:si konfiguraatiossa varmenteeksi uusi varmenne.
Nyt voit poistaa vanhan varmenteen metadatasta Resurssirekisterillä

CSC

Osiot

Aliosiot