streamalism.org

1. Oversikt

I denne artikkelen vil vi fokusere på de viktigste brukssakene for X.509 sertifikatgodkjenning - verifisere identiteten til en kommunikasjonskompis når du bruker HTTPS (HTTP over SSL) -protokollen.

Enkelt sagt - mens en sikker forbindelse opprettes, verifiserer klienten serveren i henhold til sertifikatet (utstedt av en klarert sertifikatmyndighet).

Men utover det kan X.509 i Spring Security brukes til verifisere identiteten til en klient av serveren mens du kobler til. Dette kalles "Gjensidig autentisering", og vi vil se på hvordan det gjøres også her.

Til slutt vil vi ta på når det er fornuftig å bruke denne typen autentisering.

For å demonstrere serverbekreftelse oppretter vi et enkelt webapplikasjon og installerer en tilpasset sertifikatmyndighet i en nettleser.

Videre for gjensidig autentisering, vi oppretter et klientsertifikat og endrer serveren vår for kun å tillate bekreftede klienter.

Det anbefales sterkt å følge opplæringen trinn for trinn og opprette sertifikatene, i tillegg til nøkkelbutikken og tillitsbutikken, i henhold til instruksjonene i de følgende avsnittene. Imidlertid kan alle filene som er klare til bruk bli funnet i GitHub-depotet vårt.

2. Selvsignert rot CA

For å kunne signere sertifikatene på serversiden og klientsiden, må vi først lage vårt eget selvsignerte root CA-sertifikat. Denne måten vi vil fungere som vår egen sertifikatmyndighet.

For dette formålet bruker vi openssl-biblioteket, så vi må ha det installert før vi følger neste trinn.

La oss nå opprette CA-sertifikatet:

openssl req -x509 -sha256-dager 3650 -nøkkel rsa: 4096 -keyout rootCA.key -out rootCA.crt

Når vi utfører kommandoen ovenfor, må vi oppgi passordet for den private nøkkelen vår. For formålet med denne opplæringen bruker vi endre det som passordfrase.

I tillegg vi må oppgi informasjon som danner et såkalt særnavn. Her gir vi bare CN (Common Name) - Baeldung.com - og lar andre deler være tomme.

3. Keystore

Valgfritt krav: For å bruke kryptografisk sterke nøkler sammen med krypterings- og dekrypteringsfunksjoner trenger vi “Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files”Installert i vår JVM.

Disse kan for eksempel lastes ned fra Oracle (følg installasjonsinstruksjonene som er inkludert i nedlastingen). Noen Linux-distribusjoner gir også en installerbar pakke gjennom deres pakkeforvaltere.

En nøkkelbutikk er et lager som vår Spring Boot-applikasjon vil bruke til å holde serverens private nøkkel og sertifikat. Med andre ord, applikasjonen vår vil bruke nøkkelbutikken til å servere sertifikatet til klientene under SSL-håndtrykket.

I denne opplæringen bruker vi Java Key-Store (JKS) format og et keytool kommandolinjeverktøy.

3.1. Server-sertifikat

For å implementere serversiden X.509-autentisering i vår Spring Boot-applikasjon, vi først må du opprette et server-sertifikat.

La oss begynne med å lage en såkalt sertifikatsigneringsforespørsel (CSR):

openssl req -new -newkey rsa: 4096 -keyout localhost.key –out localhost.csr

På samme måte, som for CA-sertifikatet, må vi oppgi passordet for den private nøkkelen. I tillegg, la oss bruke lokal vert som et vanlig navn (CN).

Før vi fortsetter, må vi opprette en konfigurasjonsfil - localhost.ext. Det lagrer noen ekstra parametere som trengs under signering av sertifikatet.

AuthorityKeyIdentifier = keyid, utsteder basicConstraints = CA: FALSE subjectAltName = @alt_names [alt_names] DNS.1 = localhost

En fil som er klar til bruk er også tilgjengelig her.

Nå er det på tide å signere forespørselen med vår rootCA.crt sertifikat og den private nøkkelen:

openssl x509 -req -CA rootCA.crt -CAkey rootCA.key -in localhost.csr -out localhost.crt -days 365 -CAcreateserial -extfile localhost.ext

Merk at vi må oppgi det samme passordet som vi brukte da vi opprettet CA-sertifikatet.

Sånn som det er nå, vi har endelig en klar til bruk localhost.crt sertifikat signert av vår egen sertifikatmyndighet.

For å skrive ut sertifikatets detaljer i en lesbar form, kan vi bruke følgende kommando:

openssl x509 -in localhost.crt -tekst

3.2. Importer til Keystore

I denne delen vil vi se hvordan du gjør det importer det signerte sertifikatet og den tilhørende private nøkkelen til keystore.jks fil.

Vi bruker PKCS 12-arkivet til å pakke serverens private nøkkel sammen med det signerte sertifikatet. Så importerer vi den til det nyopprettede keystore.jks.

Vi kan bruke følgende kommando til å lage en .p12 fil:

openssl pkcs12 -export -out localhost.p12 -name "localhost" -keykey localhost.key -in localhost.crt

Så vi har nå localhost.key og localhost.crt samlet i singelen localhost.p12 fil.

La oss nå bruke keytool til lage en keystore.jks repository og importere localhost.p12 filen med en enkelt kommando:

nøkkelverktøy -importkeystore -srckeystore localhost.p12 -srcstoretype PKCS12 -destkeystore keystore.jks -deststoretype JKS

På dette stadiet har vi alt på plass for serverautentiseringsdelen. La oss fortsette med vår konfigurasjon av Spring Boot-applikasjonen.

4. Eksempel på bruk

Vårt SSL-sikrede serverprosjekt består av en @SpringBootApplication kommentert applikasjonsklasse (som er en slags @Konfigurasjon), en application.properties konfigurasjonsfil og en veldig enkel MVC-stil front-end.

Alt, applikasjonen må gjøre, er å presentere en HTML-side med en "Hei {bruker}!" beskjed. På denne måten kan vi inspisere serversertifikatet i en nettleser for å sikre at forbindelsen er bekreftet og sikret.

4.1. Maven avhengigheter

Først oppretter vi et nytt Maven-prosjekt med tre Spring Boot Starter-pakker inkludert:

 org.springframework.boot spring-boot-starter-security org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-thymeleaf 

For referanse: vi kan finne pakkene på Maven Central (sikkerhet, web, thymeleaf).

4.2. Spring Boot Application

Som neste trinn oppretter vi hovedapplikasjonsklassen og brukerkontrolleren:

@SpringBootApplication public class X509AuthenticationServer {public static void main (String [] args) {SpringApplication.run (X509AuthenticationServer.class, args); }} @Controller public class UserController {@RequestMapping (value = "/ user") public String user (Model model, Principal principal) {UserDetails currentUser = (UserDetails) ((Authentication) principal) .getPrincipal (); model.addAttribute ("brukernavn", currentUser.getUsername ()); returner "bruker"; }}

Nå forteller vi applikasjonen hvor du finner vår keystore.jks og hvordan du får tilgang til den. Vi setter SSL til en "aktivert" status og endrer standard lytterport til angi en sikret tilkobling.

I tillegg konfigurerer vi noen brukerdetaljer for tilgang til serveren vår via grunnleggende godkjenning:

server.ssl.key-store = .. / store / keystore.jks server.ssl.key-store-password = $ {PASSWORD} server.ssl.key-alias = localhost server.ssl.key-password = $ {PASSWORD } server.ssl.enabled = true server.port = 8443 spring.security.user.name = Admin spring.security.user.password = admin

Dette vil være HTML-malen, plassert på ressurser / maler mappe:

   X.509 Autentiseringsdemo 
Hallo !

4.3. Root CA Installasjon

Før vi fullfører denne delen og ser på nettstedet, vi må installere vår genererte rotsertifikatmyndighet som et klarert sertifikat i en nettleser.

En eksemplarisk installasjon av sertifikatmyndigheten vår for Mozilla Firefox ser slik ut:

1. Type om: preferanser i adressefeltet
2. Åpen Avansert -> Sertifikater -> Vis sertifikater -> Myndigheter
3. Klikk på Import
4. Finn Baeldung tutorials mappen og undermappen vår-sikkerhet-x509 / keystore
5. Velg rootCA.crt fil og klikk OK
6. Velg “Stol på denne CAen for å identifisere nettsteder ” og klikk OK

Merk: Hvis du ikke vil legge til vår sertifikatmyndighet til listen over klarerte myndigheter, har du senere muligheten til å lage en unntak og vis nettstedet tøft, selv når det er nevnt som usikkert. Men så ser du et 'gult utropstegn' -symbol i adresselinjen, som indikerer den usikre forbindelsen!

Etterpå navigerer vi til spring-security-x509-basic-auth modul og kjør:

mvn spring-boot: run

Til slutt traff vi // localhost: 8443 / bruker, skriv inn brukerlegitimasjonen vår fra application.properties og skal se a “Hei Admin!” beskjed. Nå kan vi inspisere tilkoblingsstatusen ved å klikke på "grønn lås" -symbolet i adressefeltet, og det skal være en sikret forbindelse.

5. Gjensidig godkjenning

I forrige avsnitt presenterte vi hvordan du implementerer det vanligste SSL-autentiseringsskjemaet - server-autentisering. Dette betyr at bare en server autentiserte seg selv mot klienter.

I denne seksjonen, vi vil beskrive hvordan du legger til den andre delen av autentiseringen - autentisering på klientsiden. På denne måten er det kun klienter med gyldige sertifikater signert av autoriteten som serveren vår stoler på, som får tilgang til vårt sikre nettsted.

Men før vi fortsetter, la oss se hva som er fordeler og ulemper ved å bruke den gjensidige SSL-godkjenningen.

Fordeler:

• Den private nøkkelen til en X.509 klientsertifikat er sterkere enn noe brukerdefinert passord. Men det må holdes hemmelig!
• Med et sertifikat, identiteten til en klient er velkjent og lett å verifisere.
• Ingen flere glemte passord!

Ulemper:

• Vi må lage et sertifikat for hver nye klient.
• Kundens sertifikat må installeres i et klientprogram. Faktisk: X.509 klientautentisering er enhetsavhengig, som gjør det umulig å bruke denne typen autentisering i offentlige områder, for eksempel på en internettkafé.
• Det må være en mekanisme for å tilbakekalle kompromitterte klientsertifikater.
• Vi må opprettholde klientsertifikatene. Dette kan lett bli kostbart.

5.1. Truststore

En trustsore på en eller annen måte er det motsatte av en keystore. Den har sertifikatene til de eksterne enhetene vi stoler på.

I vårt tilfelle er det nok å beholde rot-CA-sertifikatet i tillitsbutikken.

La oss se hvordan du lager en truststore.jks fil og importere rootCA.crt ved hjelp av hovedverktøy:

keytool -import -trustcacerts -noprompt -alias ca -ext san = dns: localhost, ip: 127.0.0.1 -fil rootCA.crt -keystore truststore.jks

Merk at vi må oppgi passordet for det nyopprettede trusstore.jks. Her brukte vi igjen endre det passordfrase.

Det er det, vi har importert vårt eget CA-sertifikat, og truststore er klar til bruk.

5.2. Vårs sikkerhetskonfigurasjon

For å fortsette endrer vi vår X509AuthenticationServer å utvide fra WebSecurityConfigurerAdapter og overstyre en av de angitte konfigureringsmetodene. Her konfigurerer vi x.509-mekanismen for å analysere Vanlig navn (CN) felt av et sertifikat for utvinning av brukernavn.

Med disse ekstraherte brukernavnene ser Spring Security opp i et gitt UserDetailsService for samsvarende brukere. Så vi implementerer også dette tjenestegrensesnittet som inneholder en demo-bruker.

Tips: I produksjonsmiljøer, dette UserDetailsService kan laste brukerne for eksempel fra en JDBC-datakilde.

Du må legge merke til at vi kommenterer klassen vår med @EnableWebSecurity og @EnableGlobalMethodSecurity med aktivert pre- / post-autorisasjon.

Med sistnevnte kan vi kommentere ressursene våre med @PreAuthorize og @PostAuthorize for finkornet tilgangskontroll:

@SpringBootApplication @EnableWebSecurity @EnableGlobalMethodSecurity (prePostEnabled = true) public class X509AuthenticationServer utvider WebSecurityConfigurerAdapter {... @Override-beskyttet ugyldig konfigurering (HttpSecurity http) kaster Exception $) ") service service)) brukerDetaljer (bruker service)) {return new UserDetailsService () {@Override public UserDetails loadUserByUsername (String username) {if (username.equals ("Bob")) {return new User (username, "", AuthorityUtils .commaSeparatedStringToAuthorityList ("ROLE_USER"));} throw nytt brukernavnNotFoundException ("Bruker ikke funnet!");}};}}

Som sagt tidligere, er vi nå i stand til å bruke Uttrykkbasert tilgangskontroll i kontrolleren vår. Mer spesifikt respekteres autorisasjonsnotatene våre på grunn av @EnableGlobalMethodSecurity kommentar i vår @Konfigurasjon:

@Controller offentlig klasse UserController {@PreAuthorize ("hasAuthority ('ROLE_USER')") @RequestMapping (verdi = "/ bruker") offentlig strengbruker (modellmodell, rektor) {...}}

En oversikt over alle mulige autorisasjonsalternativer finner du i offisiell dokumentasjon.

Som et siste modifiseringstrinn må vi fortelle applikasjonen hvor vår truststore ligger og det SSL-klientautentisering er nødvendig (server.ssl.client-auth = behov).

Så vi legger følgende inn i vårt application.properties:

server.ssl.trust-store = store / truststore.jks server.ssl.trust-store-password = $ {PASSWORD} server.ssl.client-auth = behov

Nå, hvis vi kjører applikasjonen og peker nettleseren mot // localhost: 8443 / bruker, blir vi informert om at jevnaldrende ikke kan bekreftes, og det nekter å åpne nettstedet vårt.

5.3. Kundesertifikat

Nå er det på tide å opprette sertifikatet på klientsiden. Fremgangsmåten vi må ta, er ganske mye den samme som for serversertifikatet vi allerede har opprettet.

Først må vi opprette en forespørsel om signering av sertifikat:

openssl req -nytt -nøkkelkey ​​rsa: 4096 -noder -keyout clientBob.key –out clientBob.csr

Vi må gi informasjon som vil bli innlemmet i sertifikatet. For denne øvelsen, la oss bare angi det vanlige navnet (CN) - Bob. Det er viktig da vi bruker denne oppføringen under autorisasjonen, og bare Bob blir gjenkjent av eksempelsøknaden vår.

Deretter må vi signere forespørselen med vår CA:

openssl x509 -req -CA rootCA.crt -CAkey rootCA.key -in clientBob.csr -out clientBob.crt -days 365 -CAcreateserial

Det siste trinnet vi må ta er å pakke det signerte sertifikatet og den private nøkkelen i PKCS-filen:

openssl pkcs12 -export -out clientBob.p12 -name "clientBob" -keykeyBob.key -in clientBob.crt

Endelig, vi er klare til å installere klientsertifikatet i nettleseren.

Igjen, vi bruker Firefox:

1. Type om: preferanser i adressefeltet
2. Åpen Avansert -> Vis sertifikater -> Sertifikatene dine
3. Klikk på Import
4. Finn Baeldung tutorials mappen og undermappen vår-sikkerhet-x509 / butikk
5. Velg clientBob.p12 fil og klikk OK
6. Skriv inn passordet for sertifikatet ditt og klikk OK

Nå, når vi oppdaterer nettstedet vårt, blir vi bedt om å velge klientsertifikatet vi vil bruke:

Hvis vi ser en velkomstmelding som "Hei Bob!", det betyr at alt fungerer som forventet!

6. Gjensidig autentisering med XML

Legger til X.509 klientautentisering til en http sikkerhetskonfigurasjon i XML er også mulig:

 ...         ... 

For å konfigurere en underliggende Tomcat, må vi sette vår keystore og vår truststore inn i sitt konf mappen og rediger server.xml:

Tips: Med clientAuth satt til “Vil”, SSL er fortsatt aktivert, selv om klienten ikke gir et gyldig sertifikat. Men i dette tilfellet må vi bruke en andre autentiseringsmekanisme, for eksempel et påloggingsskjema, for å få tilgang til de sikrede ressursene.

7. Konklusjon

Oppsummert har vi lært hvordan du lager et selvsignert CA-sertifikat og hvordan du bruker det til å signere andre sertifikater.

I tillegg har vi laget både sertifikater på serversiden og klientsiden. Så har vi presentert hvordan du importerer dem til en keystore og en truststore tilsvarende.

Videre skal du nå kunne pakke et sertifikat sammen med sin private nøkkel i PKCS12-format.

Vi har også diskutert når det er fornuftig å bruke Spring Security X.509 klientautentisering, så det er opp til deg å bestemme om du skal implementere det i webapplikasjonen din eller ikke.

Og for å avslutte, finn kildekoden til denne artikkelen på Github.