Versionen im Vergleich

Alte Version 13

changes.mady.by.user Brand Peter

Gespeichert am

verglichen mit

Neue Version Aktuell

changes.mady.by.user Peter Brand

Gespeichert am

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.
Kommentar: rm links to old TCS supplieer

...

Hinweis
iconfalse
titleThis Guide assumes
  • A fresh, minimal (e.g. netinst.iso) install of Debian 12 ("Bookworm") with no "tasks" except openssh-server
    • Unfortunately Ubuntu 24.04 LTS ("Noble Numbat") Server works the same as Debian 12 for the purpose of this guidecan no longer be recommended, see the warning on the page Shibboleth IDP 5.
  • Accessed via SSH or the console (no GUI/X11/wayland required and certainly not recommended),
  • Correct server time configuration using NTP (e.g. using systemd-timesyncd or ntpd)
  • Packet filters or firewall rules in place, e.g.:
    • With outgoing(ports TCP/80 and TCP/443) network access:
      • Port 80 for Debian APT updates, i.e., for downloading signed software packages
      • Port 80 and 443 for downloading cryptographically signed eduID.at Metadata documents.
      • Port 443 is also needed for downloads of the Shibboleth IDP software or additional modules
      • With local authentication the IDP will likely also need to connect to your LDAP Directory Servers for authentication and attribute lookup,
        • either on the standard port TCP/389 for LDAP(+STARTTLS),
        • or on port TCP/636 for LDAPS (which which no formal specification exists),
        • or maybe on the "global catalog" port of your Microsoft Active Directory (only if it's necessary you access that).
      • For access to NTP services you also need outgoing connectivity to the configured NTP servers (e.g. ACOnet's)
    • And incoming HTTPS access on port TCP/443 only. Noone needs to access your IDP by manually entering its URL, so no need to even have the IDP listening on TCP/80 publically, and therefore also no need for a redirect from TCP/80 to TCP/443.
      • Also, if the server is managed via SSH you'll need to allow access to port TCP/22, though only from a secured management network.
  • All commands in this guide to be issued by user root (uid=0) so sudo -s first as needed.
  • The shell used is /bin/bash (you can get fancy with fish/zsh/etc. after finishing the install/configuration if you want)
  • Use of systemd for service management, in order to use the amended service unit contained in this documentation.

...

Equipped with the CSR you can now request a TLS certificate based from your CA, e.g. using the using ACOnet TCS supplier. Once the certificate has been issued copy it to the IDP server as webserver.crt.
You'll also need to copy any intermediary Certificate Authority (CA) certificates to the IDP server.

Info

In case of ACOnet TCS, Sectigo and an RSA OV certificate the only intermediate CA certificate you'll need is the one with the subject "C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4", referenced as file GEANT-OV-RSA-CA-4.crt below.

Convert the TLS/SSL keypair into PKCS12

Copy the private key, new TLS certificate and any intermediate CA certificates into a PKCS#12 keystore file:

!

Convert the TLS/SSL keypair into PKCS12

Copy the private key, new TLS certificate and any intermediate CA certificates into a PKCS#12 keystore file:

Kein Format
openssl pkcs12 -export -in webserver.crt -inkey webserver.key -certfile MATCHING-INTERMEDIATE-CA-CERTS
Kein Format
openssl pkcs12 -export -in webserver.crt -inkey webserver.key -certfile GEANT-OV-RSA-CA-4.crt -name webserver -out webserver.p12

...

Kein Format
openssl s_client -CApath /etc/ssl/certs/ -connect webserver-fqdn:443 2>&1 </dev/null | grep -A8 "^Certificate chain"[si]:

and verify that it looks something like the "Certificate chain" presented below. The Subject of cert 0 will obviously differ, and depending on your choice of CA or certificate product the CA or certificate chain may also be different. A correct chain (and therfore PKCS#12 keystore) for TLS usage should contain all the certificates up until but excluding the root CA certificate. I.e, in the example below the certificate with CN = USERTrust RSA Certification Authority is Hellenic Academic and Research Institutions RootCA 2015 is not included in the chain sent from the server (but must be known by the web browser):.

Kein Format
 0 s:C = AT, ST = Wien, O = Universit\C3\A4t Wien, CN = idp.aco.net                  
   i:C = GR, O = Hellenic Academic and Research Institutions CA, CN = GEANT TLS RSA 1
 1
Kein Format
Certificate chain
 0 s:C = ATGR, postalCodeO = 1010,Hellenic STAcademic =and Wien,Research LInstitutions = WienCA, streetCN = UniversitaetsstrasseGEANT 7,TLS O = ACOnet, CN = idp.aco.netRSA 1
   i:C = NLGR, O = GEANT Vereniging Hellenic Academic and Research Institutions CA, CN = GEANTHARICA OVTLS RSA Root CA 42021
 12 s:C = NLGR, O = GEANT Vereniging Hellenic Academic and Research Institutions CA, CN = GEANTHARICA OVTLS RSA Root CA 42021
   i:C = USGR, STL = New JerseyAthens, LO = JerseyHellenic City,Academic Oand =Research TheInstitutions USERTRUSTCert. NetworkAuthority, CN = USERTrust RSA Certification Authority Hellenic Academic and Research Institutions RootCA 2015

In case of errors check the output of "journalctl -u tomcat10 -ef".

...