Versions Compared

Old Version 9

changes.mady.by.user Peter Brand

Saved on

compared with

New Version Current

changes.mady.by.user Peter Brand

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: 2024: 2k RSA still ok

...

Note
iconfalse
titleThis Guide assumes
  • A fresh, minimal (e.g. netinst.iso) install of Debian 1011 ("BusterBullseye") with no "tasks" except openssh-server
    • Ubuntu 18.04 LTS ("xenial") Server works the same as Debian 10 11 for the purpose of this guide
  • Accessed via SSH or the console (no X11 required nor 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 signed eduID.at Metadata
      • Port 443 is also needed for downloads of the Shibboleth IDP software (you can copy that to the server yourself, of course)or additional modules
      • The IDP will 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 you need to access that).
      • For NTP 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 manually by entering its URL, no port 80 necessary nor recommended),so no need to be even listening on TCP/80 and therefore also no need for a redirect from TCP/80 to TCP/443.
      • Also incoming port TCP/22 for access only from a management
      • also incoming port 22 for access only from a management network, if the server is managed via SSH,
  • All commands in this guide are to be issued by user root (uid=0) , and will make of setuidgid as needed to change to other accountsso sudo -s first as needed.
  • The shell to use is /bin/bash (you can get fancy with fish/zsh/etc. after finishing the install/configuration)
  • Use of systemd for service management using the amended service unit as described in this documentation

...

Install required (and used, throughout this documentation) packages, possibly replacing vim with your $EDITOR of choice (e.g. emacs-nox or nano, both of which also support syntax highlighting, which helps when editing XML files) and stop the automatically started tomcat until we've completed more configuration performed further below:

No Format
apt install --no-install-recommends default-jdk-headless tomcat9 \
  vim less openssl unzip curl expat multitail gnupg net-tools

systemctl stop tomcat9

...

Tip
titleRenewing an existing TLS certificate?

In case you're replacing an expiring TLS certificate where the matching private key is still considered to be secure and of sufficient strength (in 2021 2024 CE for RSA keys that means a key size of at least 2048 bits) you may want to keep using the existing private key (and PKCS#12 keystore passphrase) and generate the CSR from that key.
To do that first extract the private key from your keystore (instead of generating a new one):

No Format
openssl pkcs12 -in /etc/tomcat9/webserver.p12 -nocerts | tail +5 > webserver.key

When asked to "Enter Import Password" supply the existing keystorePass for the  port="443" Connector from your /etc/tomcat9/server.xml configuration file.
When asked to "Enter PEM pass phrase" simply enter/paste that same passphrase again.
And yet again, when asked to "Verifying - Enter PEM pass phrase".

Then generate a CSR from the extracted private key, either by supplying the necessary data (at least the subject) on the command line or by entering any data interactively when being prompted for it (when not adding -subj to the command):

No Format
openssl req -new -key webserver.key -out webserver.csr -subj "/CN=WEBSERVER-FQDN"

When asked to "Enter pass phrase for webserver.key" again provide the passphrase from the previous steps.

The content of webserver.csr is what you provide to your CA then, e.g. via cat webserver.csr and pasting the result into the CA's web interface.

...

By default Tomcat logs everything multiple times, including to /var/log/tomcat9/catalina.$date.logout and /var/log/tomcat9/localhost.$date.log*, which we don't care for. So let's create a backup copy of Tomcat's logging.properties and replace its content with the minumum needed to get an access log comparable to Apache httpd written to /var/log/tomcat9/access.log. Tomcat's stdout/stderr will go to the systemd journal. There will be no catalina.out to manageTomcat's stdout/stderr to the console (which ends up in the systemd journal in our configuration). To prevent catalina.out from being created we deacticate it further below (in our "Systemd service" override) by setting the CATALINA_OUT=/dev/null environment variable for the java process.

No Format
systemctl stop tomcat9
cp -a /etc/tomcat9/logging.properties /etc/tomcat9/logging.properties.`date -u +%Y%m%d`
 
echo -n 'handlers = java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = INFO
java.util.logging.ConsoleHandler.formatter = org.apache.juli.SystemdFormatter
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = java.util.logging.ConsoleHandler
' > /etc/tomcat9/logging.properties

...

No Format
rm -f /var/log/tomcat9/*
systemctl restart tomcat9
ls -l /var/log/tomcat9/
multitail /var/log/tomcat9/* -l 'journalctl -u tomcat9.service -f'  # exit with 'q'
systemctl stop tomcat9

Since If you're certain there's no catalina.log file being generated anymore we you can also disable the default logrotate config snippet for it:

No Format
sed -i 's/^/#/' /etc/logrotate.d/tomcat9

Systemd service

Debian 10's Tomcat comes with an almost-usable systemd service that needs to be amended in order to

  1. avoid Avoid the systemd-house-of-horror that's still all too common with Tomcat packaging, and-horror that's still all too common with Tomcat/Java packaging
  2. Avoid slow startup times due to use of a blocking /dev/random (cf. Myths about urandom also linked from the Shib wiki).
  3. Allow allow the IDP application to write logs and metadata to the filesystem as needed
  4. Try avoiding the creation of catalina.out (we already have its content in journald using this configuration)

And since we're creating an override for the system-supplied systemd service unit anyway we'll also set the maximum memory usage there ("-Xmx3g" in the example below, i.e., 3GB).
Adjust as needed, but 3-4GB should be sufficient even for large metadata aggregates (as are common with Interfederation). Also leave a bit of RAM for the OS. (wink) (Not that you should be running anything else on an IDP server.)

...