was - certbot tomcat

Web/WAS 2017.02.21 05:33

Recipe for Let’s Encrypt on an API Server

This post is part of a seriesabout my experiences moving our library servers and services to Let’s Encrypt for TSL/HTTPS certificates.  This  recipe will be describing how I installed certificates from Let’s Encrypt on an API server, more specifically an Apache Tomcat 7 web application called Web Services from SirsiDynix which is installed on a local server running CentOS 6.  At our library, Web Services provides integration between two SirsiDynix products–Enterprise OPAC, BookMyne mobile application–and the library management system, mostly for “my account” functions such as holds and renewals.  In addition, we use Web Services to integrate real-time availability from the the library management system in the search results for Enterprise, Summon, and Ebsco Discovery Services.

Note: these instructions are for Enterprise installed on a local server, if your Web Services server is hosted by SirsiDynix, you would need to work with them to install HTTPS certificates.

Here are the overall steps on a local Web Services server that you have shell access to with root or appropriate sudo privileges.

  • Get the client application.
  • Use the client application to generate certificates.
  • Configure Tomcat to use the certificates.
  • Set up a routine for renewal of certificates.

Get the Client Application

Let’s Encrypt recommends using a client application called certbot to obtain certificates.   For a number of distros (Ubuntu, ArchLinux, Gentoo, CentOS RHEL 7), the client is available via the common package manager for that distro and can be installed with one command.  Our server is still on CentOS 6, so we have a few extra steps.

  • Enable the EPEL (Extra Packages for Enterprise Linux) repository.  This will make additional dependencies available to the certbot client.
$ sudo yum install epel-release
  • Create a directory for where the certbot client will live, this can be anywhere but I selected /usr/local/ and named the directory letsencrypt.
$ sudo mkdir /usr/local/letsencrypt
$ cd /usr/local/letsencrypt
  • Download the certbot client and make it executable.
$ sudo wget https://dl.eff.org/certbot-auto
$ sudo chmod a+x certbot-auto

Generate Certificates

The certbot client is actually a script that performs a number of tasks, see this previous post for more details.

  • Run the certbot client to install certificates in manual mode.
$ cd /usr/local/letsencrypt
$ sudo ./certbot-auto --standalone --standalone-supported-challenges http-01 certonly -d jlc-service.uaa.alaska.edu

The  –standalone switch tells certbot to install the certificates in the /etc/letsencrypt/ directory.  The –standalone-supported-challenges http-01 switch tells certbot to bind temporarily to port 80 to verify that you own the server.  Therefore port 80 must be available via the firewall and have no services running on it during this step.

  • Answer the questions the client will ask and wait for it to finish.
email address?
I put in my email address.
Agree to Let's Encrypt's terms

Configure Tomcat to Use the Certificates

There are two possible methods for installing HTTPS certificates for Apache Tomcat depending on how the application is configured:

  • Direct access – configure Tomcat to use a Java Key Store that houses the certificates
  • Proxy access – configure Apache to use the certificates

Web Services uses direct access to the Tomcat application so we be creating a Java Key Store to house the certificates.  Our previous post on installing Let’s Encrypt certificates on an OPAC Server covered configuring Tomcat for proxy access via Apache.

  • Install Java Development Kit version 1.7 or higher so that TLSv1.2 is available.
$ sudo yum install java-1.8.0-openjdk
  • Change directory to where your Tomcat configuration files are located, in our case that’s in /opt.
$ cd /opt/tomcat/conf
  • Bundle Let’s Encrypt certificates into a single file in the PKCS #12format.
$ sudo openssl pkcs12 -export -in /etc/letsencrypt/live/jlc-service.uaa.alaska.edu/fullchain.pem -inkey /etc/letsencrypt/live/jlc-service.uaa.alaska.edu/privkey.pem -out <boundcertificates>.p12 -name <aliasname>
  • Answer the question to create the export password.
Enter export password: <firstpassword>
Verify password: <firstpassword>
  • Create the Java Key Store.
$ sudo keytool -importkeystore -deststorepass <secondpassword> -destkeypass <thirdpassword> -destkeystore <keystorename>.jks -srckeystore <boundcertificates>.p12 -srcstoretype PKCS12 -srcstorepass <firstpassword> -alias <aliasname>

The <boundcertificates>, <aliasname>,<firstpassword>, <secondpassword>, <thirdpassword>, and <keystorename> that you assign in these two commands should be recorded and kept in a safe place so these steps can be repeated again when needed.

  • Edit the Tomcat configuration file to tell it to use the certificates on port 8443.
$ sudo nano server.xml

In our case, there was a default entry for 8443 using vendor self-signed certificates and configuration which allowed insecure SSL v2 & v3.

<Connector port="8443"
 noCompressionUserAgents="gozilla, traviata"
 server="SirsiDynix IlsWS"

We changed it to the following.

<Connector port="8443"
 noCompressionUserAgents="gozilla, traviata"
 sslEnabledProtocols = "TLSv1.2,TLSv1.1,TLSv1"
 server="SirsiDynix IlsWS"
  • Restart Tomcat service
$ sudo service Tomcat7 restart
  • Test the certificates to make sure they are installed correctly for the domain.

Note: I normally use https://www.ssllabs.com/ssltest/  but it only supports testing on port 443.  HT Bridge provides testing on any port you specify.

That’s it, our library API server is now using free HTTPS certificates issued by Let’s Encrypt.  We can now work on moving our production OPAC server to HTTPS (we covered moving our test OPAC server to HTTPS in the previous post).

Certificate Renewal

Let’s Encrypt will only issue certificates for 90 days for some good reasons but this comes as quite a shock to administrators who are used to  1-3 year renewal periods.  The idea is that renewal will be automatic so that you will only need to manually deal with certificates when first issuing them or when making changes to domain names.

  • Perform a dry-run to renew certificates without making a real request.  You should get a message that the test succeeded.
$ cd /usr/local/letsencrypt
$ sudo ./certbot-auto renew --dry-run
  • Add a cron or systemd job to run the command automatically.  The certificates will only renew if they are going to expire in 30 days or less.  Let’s Encrypt recommends running the renewal command twice a day.  I’m old school so decided to use crontab.

$ sudo crontab -e

Here is an example entry to run renewal once a day at 4:25am.
25 04 * * * /usr/local/letsencrypt/./certbot-auto renew –quiet

  • Bundle the renewed certificates into a single PKCS file and create (i.e. replace) the Java Key Store using the steps outlined above and restart Tomcat service.  It should be fairly straightforward to create a bash script that performs these steps and schedule it to run automatically.

Next Post

This completes the initial series of posts on installing Let’s Encrypt certificates on a variety of local servers at our library.   In the months to come, I will be tackling the following:

  • Best practices for preparing your website to migrate to HTTPS
  • Trying to install Let’s Encrypt certificates on ILS server
  • Trying to install Let’s Encrypt certificates on several different commercial Web hosting platforms
  • Trying to install Let’s Encrypt certificates on other types of servers (VPN, Squid proxy, mail)

So stay tuned!

source - https://consortiumlibrary.org/blogs/mcrobinson/blog/2016/07/26/recipe-for-lets-encrypt-on-an-api-server/

저작자 표시
Posted by linuxism

eq exists (as well as nelt, etc) so you can avoid using XML entity references (< is an XML character and would need to be escaped as &lt;, for example), but they do the same thing.

See Comparison operators in JSP for more info.

Entirely correct, they're exactly the same. The characterbased operators are only XML-safe.

source - http://stackoverflow.com/questions/2087721/difference-between-eq-and-in-jsp

저작자 표시

'Development > JSP & Servlet' 카테고리의 다른 글

jsp - difference between eq and ==  (0) 2017.02.03
jsp - 컴파일(compile)  (0) 2016.05.13
jsp - jstl fn:contains  (0) 2014.07.10
서블릿(servlet) 이해  (0) 2013.12.31
servlet - 3.0 비동기 기능  (0) 2013.07.27
servlet - 필터(filter)  (0) 2013.07.27
Posted by linuxism

Chapter 3. Configuring the Date and Time

Modern operating systems distinguish between the following two types of clocks:
  • real-time clock (RTC), commonly referred to as a hardware clock, (typically an integrated circuit on the system board) that is completely independent of the current state of the operating system and runs even when the computer is shut down.
  • system clock, also known as a software clock, that is maintained by the kernel and its initial value is based on the real-time clock. Once the system is booted and the system clock is initialized, the system clock is completely independent of the real-time clock.
The system time is always kept in Coordinated Universal Time (UTC) and converted in applications to local time as needed. Local time is the actual time in your current time zone, taking into account daylight saving time (DST). The real-time clock can use either UTC or local time. UTC is recommended.
Fedora 25 offers three command line tools that can be used to configure and display information about the system date and time: the timedatectl utility, which is new in Fedora 25 and is part of systemd; the traditional date command; and the hwclock utility for accessing the hardware clock.

3.1. Using the timedatectl Command

The timedatectl utility is distributed as part of the systemd system and service manager and allows you to review and change the configuration of the system clock. You can use this tool to change the current date and time, set the time zone, or enable automatic synchronization of the system clock with a remote server.
For information on how to display the current date and time in a custom format, see also Section 3.2, “Using the date Command”.

3.1.1. Displaying the Current Date and Time

To display the current date and time along with detailed information about the configuration of the system and hardware clock, run the timedatectl command with no additional command line options:
This displays the local and universal time, the currently used time zone, the status of the Network Time Protocol (NTP) configuration, and additional information related to DST.
Example 3.1. Displaying the Current Date and Time
The following is an example output of the timedatectl command on a system that does not use NTP to synchronize the system clock with a remote server:
~]$ timedatectl
      Local time: Mon 2013-09-16 19:30:24 CEST
  Universal time: Mon 2013-09-16 17:30:24 UTC
        Timezone: Europe/Prague (CEST, +0200)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2013-03-31 01:59:59 CET
                  Sun 2013-03-31 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2013-10-27 02:59:59 CEST
                  Sun 2013-10-27 02:00:00 CET

3.1.2. Changing the Current Time

To change the current time, type the following at a shell prompt as root:
timedatectl set-time HH:MM:SS
Replace HH with an hour, MM with a minute, and SS with a second, all typed in two-digit form.
This command updates both the system time and the hardware clock. The result it is similar to using both the date --setand hwclock --systohc commands.
The command will fail if an NTP service is enabled. See Section 3.1.5, “Synchronizing the System Clock with a Remote Server” to temporally disable the service.
Example 3.2. Changing the Current Time
To change the current time to 11:26 p.m., run the following command as root:
~]# timedatectl set-time 23:26:00

By default, the system is configured to use UTC. To configure your system to maintain the clock in the local time, run the timedatectl command with the set-local-rtc option as root:
timedatectl set-local-rtc boolean
To configure your system to maintain the clock in the local time, replace boolean with yes (or, alternatively, ytruet, or 1). To configure the system to use UTC, replace boolean with no (or, alternatively, nfalsef, or 0). The default option is no.

3.1.3. Changing the Current Date

To change the current date, type the following at a shell prompt as root:
timedatectl set-time YYYY-MM-DD
Replace YYYY with a four-digit year, MM with a two-digit month, and DD with a two-digit day of the month.
Note that changing the date without specifying the current time results in setting the time to 00:00:00.
Example 3.3. Changing the Current Date
To change the current date to 2 June 2013 and keep the current time (11:26 p.m.), run the following command as root:
~]# timedatectl set-time "2013-06-02 23:26:00"

3.1.4. Changing the Time Zone

To list all available time zones, type the following at a shell prompt:
timedatectl list-timezones
To change the currently used time zone, type as root:
timedatectl set-timezone time_zone
Replace time_zone with any of the values listed by the timedatectl list-timezones command.
Example 3.4. Changing the Time Zone
To identify which time zone is closest to your present location, use the timedatectl command with the list-timezones command line option. For example, to list all available time zones in Europe, type:
~]# timedatectl list-timezones | grep Europe
To change the time zone to Europe/Prague, type as root:
~]# timedatectl set-timezone Europe/Prague

3.1.5. Synchronizing the System Clock with a Remote Server

As opposed to the manual adjustments described in the previous sections, the timedatectl command also allows you to enable automatic synchronization of your system clock with a group of remote servers using the NTP protocol. Enabling NTP enables the chronyd or ntpd service, depending on which of them is installed.
The NTP service can be enabled and disabled using a command as follows:
timedatectl set-ntp boolean
To enable your system to synchronize the system clock with a remote NTP server, replace boolean with yes (the default option). To disable this feature, replace boolean with no.
Example 3.5. Synchronizing the System Clock with a Remote Server
To enable automatic synchronization of the system clock with a remote server, type:
~]# timedatectl set-ntp yes
The command will fail if an NTP service is not installed. See Section 14.3.1, “Installing chrony” for more information.

source - https://docs.fedoraproject.org/en-US/Fedora/25/html/System_Administrators_Guide/ch-Configuring_the_Date_and_Time.html

저작자 표시

'System > Linux' 카테고리의 다른 글

fedora - timedatectl  (0) 2016.12.17
linux - LWP  (0) 2016.12.16
linux - dnf broken  (0) 2016.12.04
linux - chmod  (0) 2016.09.03
linux - SNMP 설정(CentOS 5.6)  (0) 2016.08.25
fedora - Adding or Removing a application launcher  (0) 2016.06.26
Posted by linuxism

티스토리 툴바