Fehler: SunCertPathBuilderException: unable to find valid certification path to requested target (SSL handshake)
Fehler:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Lösung
In dem mir vorliegenden Fall musste die ein CA-Certifikat (welches das vom Server vorgezeigte Certifikat beglaubit) in den lokalen Truststore zugefügt werden.
–> Im vorliegenden Fall kann sich der Server nicht beim Caller authentifizieren.
Debugging-Möglichkeit:
-Djavax.net.debug=all
(In der Run-Config z.B. der Tomcat-Instanz)
Das bewirkt, dass interessantes geloggt wird unter: org.apache.cxf.transport.http.HTTPConduit
Auszüge davon:
Die Certificate-Chain
*** Certificate chain chain [0] = [ [ Version: V3 Subject: CN=myserver.hps.com, OU=Server, OU=CA, O=UBS, C=CH ... AuthorityInfoAccess [ [ accessMethod: caIssuers accessLocation: URIName: http://certinfo-http.hps.com/aia/HPS_Server_CA_Test_3.crt ... ] SubjectAlternativeName [ DNSName: hps.alternative.server.com ... ] ] chain [1] = [ [ Version: V3 Subject: CN=HPS Server CA Test 3, OU=CH 027, OU=CA, O=UBS, C=CH ... ]
Unter „AuthorityInfoAccess“ wird für das Certifikat ausgewiesen, durch welches andere Certifikat es beglaubigt ist. Jenes Certifikat ist auch weiter unten noch separat ausgewisen.
Das „SubjectAlternativeName“ weist alterntiven Addressen aus, für welche dieses Zertifikat als „Ausweis“ dienen kann. Alternatife zu jenem, welches in parameter „subject“ definiert ist.
Die folgende Zeile sagt, dann „certificate_unknown„, was darauf hin deutet, dass die CA (HPS Server CA Test 3) (das Ende der oben beschribenen Chain nicht bekannt is. Das heisst sie ist nicht in unserem TrustStore vorhanden.
http-apr-8080-exec-9, SEND TLSv1 ALERT: fatal, description = certificate_unknown
SSL Auswahl der vorgewiesenen Zertifikate
Welches Zertifikat wird beim SSL-Handshake vorgewiesen?
Das auszuweisende Certifikat wird über den Parameter „keyStoreAlias“ definiert.
Es entspricht im KeyStore einem Eintrag mit
Aliasname: meinServer.hps.com
Robocopy – Ersatz für xcopy – Windows-Backup über differenzierendes Kopieren (Mirroring) (Backup)
Anwendung:
robocopy source dest /MIR /XX
/MIR : Mirroring. Das heisst es wird gewährleistet, dass der Zielordner gleich aussieht wie der Source-Odner (wobei es sich bei „source“/“dest“ um Ordner handelt
/XX : Keine Löschungen von Files/Ordnern, die nur im Ziel vorkommen. (kompromittiert dahingehend das /MIR flag :-))
Referenz:
Spring Web mit Security mit Login-Page
Authorisierung via Login-Page Beispiel:
https://spring.io/guides/gs/securing-web/#initial
Einfache SPRING-MVC Web-Anwendung (Frank Hahn)
https://www.frank-rahn.de/spring-mit-einer-einfachen-webanwendung/
Spring MVC WebApp mit Parameter-Matching
Das Form-Handling-Example forn TutorialsPoint wird hier zusammengefasst.
Es zeigt, wie Formular-Felder aus einem JSP-Form in an den Controller übergeben werden und dann mit den Formularfeldern einen weitere JSP-View gefüllt und angezeigt wird.
Referenzen
HTTPS mit Client-Authentifizierung via Client-Zertifikat (Beispiel mit Spring Boot)
Bealdung hat bietet uns einen wunderbares Tutorial X.509 Authentication in Spring Security zum Thema, welchen ich hier verarbeite/zusammenfasse. Die vollständigen Sourcen sind auf GitHub verfügbar.
Zertifikates & -Stores erstellen
Das Makefile beinhaltet die ganze Magie des
- Erstellens eines Keystores (für das Server-Certifikat, das den Server ausweisen wird)
- Erstellens eines Certificate Signing Requests
- Des selbst signierens desselben CSRs (würde in Scharfem Modus von einer wirklichen Certificate Authority gemacht)
- Erstellens eines TrustStores (für die Client-Certificate Trust Authority)
- Erstellens eines Client Certificates, exportieren desselbens
Definition von HTTPS des integrated Tomcat
Wird durch diese wenigen config entries in application.properties erreicht:
server.ssl.key-store=../keystore/keystore.jks server.ssl.key-store-password=changeit server.ssl.key-alias=localhost server.ssl.key-password=changeit server.ssl.enabled=true server.port=8443 security.user.name=Admin security.user.password=admin server.ssl.trust-store=../keystore/truststore.jks server.ssl.trust-store-password=changeit server.ssl.client-auth=need
Definition der Zugriffsberechtigung in der SPRING-Boot-Applikation
Die ganze Magie der Zugriffs-Berechtigungs-Verwaltung wird durch die Annotationen @EnableWebSecurity repektive @EnableGlobalMethodSecurity und das Ableiten von WebSecurityConfigurerAdapter und dessen überschreibene Methode configure bewerkstelligt.
@SpringBootApplication @EnableWebSecurity @EnableGlobalMethodSecurity(prePostEnabled = true) public class X509AuthenticationServer extends WebSecurityConfigurerAdapter { public static void main(String[] args) { SpringApplication.run(X509AuthenticationServer.class, args); } @Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests().anyRequest().authenticated().and().x509().subjectPrincipalRegex("CN=(.*?)(?:,|$)").userDetailsService(userDetailsService()); } @Bean public UserDetailsService userDetailsService() { return new UserDetailsService() { @Override public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException { if (username.equals("cid")) { return new User(username, "", AuthorityUtils.commaSeparatedStringToAuthorityList("ROLE_USER")); } throw new UsernameNotFoundException("User not found!"); } }; } }
Die configure-Methode hat also schon via
http.authorizeRequests().anyRequest().authenticated().and().x509()
Zugriff auf das vom Web-Server empfangene Zertifikat und kann es auswerten.
Client Zertifikat in Firefox registrieren
Siehe Tutorial X.509 Authentication in Spring Security
Tomcat 8 mit HTTPS erreichtbar machen – Client Authentication via Zertifikat
A) Zertifikate erstellen
Siehe X.509 Authentication in Spring Security
B) Vorgehensweise via Tomcat-Configuration
In $CATALINA_HOME/conf/settings.xml wurde
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="8443" maxThreads="200" scheme="https" secure="true" SSLEnabled="true" <!-- Für server auth: --> keystoreFile="conf/keystore.jks" keystorePass="changeit" <!-- Für client auth: --> truststoreFile="conf/truststore.jks" truststorePass="changeit" clientAuth="true" sslProtocol="TLS"/>
eingefügt.
Dies bewirkt, dass unter Port 8443 ein Zugang angeboten wird, der TLS geschlüsselt wird.
Wenn der andere Connector
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
im settings.xml drin bleibt, dass ist per se weiterhin auch die HTTP-Adresse offen.
Die Applikation (falls keine eigene darüber installiert wurde ist das die Tomcat-Welcome-Page) ist also immernoch über
http://localhost:8080 und https://localhost:8443 erreichbar.
Wird aber eine Web-App mit web.xml mit Security constraint, wie z.B. im folgenden installiert, dann wird die definierte URL immer auf HTTPS umgeleitet.
<security-constraint>
<web-resource-collection>
<web-resource-name>Secured</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
...
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
–> Siehe StackOverflow-Artikel über Redirect
Obige Config setzt nicht nur HTTP und Server-Authentication auf, sondern auch Client-Authentication. Das bedeutet, dass wenn man auf https://localhost:8443 zugreifen möchte, man im Browser das Client-Certifikat installieren muss. Ruft man die Seite dann auf, wird einem eine Liste vom möglichen Zerts zur Wahl angeboten.
Referenzen:
Makefile in Windows ausführen – Linux-Umgebung innerhalb Windows
Problem: Wie führe ich ein Makefile in Windows aus?
Eine Lösung:
- Cygwin installieren
- Make innnerhalb Cygwin installieren. Dies wird gemacht, indem das Cygwin-Installer EXE (dasjenige, der bereits Cygwin installiert hat) ausgeführt wird. Es wird dann irgendwann eine Vielzahl von Features zur installation angeboten.
Wie erhalte ich von Cygwin Zugriff auf das Windows C-Drive?
cd /cygdrive/c