openssl

VM_CONFIG.sh

@@ -18,8 +18,7 @@ CA_DIR="/etc/pki/CA"
 mkdir -p "${CA_DIR}/newcerts"
 mkdir -p "${CA_DIR}/private"
 touch "${CA_DIR}/index.txt"
-echo 01 > "${CA_DIR}/serial"
+cp ca/serial "${CA_DIR}/serial"
-cp ca/ca.crt $CA_DIR
 
 mkdir -p /etc/openvpn/server
 mkdir -p /etc/openvpn/client

VM_OPENSSL.sh

@@ -1,7 +1,18 @@
 #!/bin/bash
 
+# configuracao
 source VM_CONFIG.sh
 if_dentro="enp0s8"
 ip_dentro="10.60.0.1"
 ifconfig $if_dentro $ip_dentro netmask 255.255.255.0
 cp conf/openssl.cnf /etc/pki/tls/
+
+# copiar ca para esta VM
+cp ca/index.txt $CA_DIR
+cp ca/ca.crt $CA_DIR
+cp ca/ca.key $CA_DIR
+cp ca/serial $CA_DIR
+cp ca/dh2048.pem $CA_DIR
+
+# correr oscp
+openssl ocsp -index $CA_DIR/index.txt -port 8888 -rsigner $CA_DIR/ca.crt -rkey $CA_DIR/ca.key -CA $CA_DIR/ca.crt -text &

VM_VPN_GATEWAY.sh

@@ -7,10 +7,19 @@
 # --- configuração --- #
 source VM_CONFIG.sh
 yum install -y google-authenticator qrencode ntpsec
+
+# NOTE(vasco): tive problemas com a sincronização de tempo
+# se nao tiver sincronizado, o TOTP nao funciona
 systemctl stop chronyd
 ntpdate pool.ntp.org
 systemctl start chronyd
 
+# NOTE(vasco): o openvpn não consegui aceder ao home e ler os secrets
+# do google authenticator, por isso fiz isto:
+mkdir -p /etc/systemd/system/openvpn-server@.service.d
+echo -e "[Service]\nProtectHome=false" > /etc/systemd/system/openvpn-server@.service.d/override.conf
+systemctl daemon-reload
+
 # --- forwarding --- #
 if_fora="enp0s8"
 ip_fora="193.136.212.1"

conf/client.conf

@@ -16,6 +16,4 @@ auth SHA256
 
 auth-user-pass
 tls-auth /etc/openvpn/client/ta.key 1
-
-remote-cert-tls server
 reneg-sec 0

enunciado.txt

@@ -0,0 +1,143 @@
+FSI 2025/2026
+Practical Assignment #2
+
+1. Goals
+•
+
+Configure a VPN tunnel in the “road warrior” scenario.
+
+•
+
+Enable two-factor user authentication with OpenVPN and Apache services.
+
+•
+
+Manage PKI: certification authorities, X.509 certificates, revocation and OCSP.
+
+2. General description
+Figure 1 illustrates the scenario considered for our practical assignment. As illustrated, secure communications are
+supported by a VPN tunnel established between a remote client (road warrior) and the VPN gateway, with the purpose of
+enabling accesses to services in the Internal Network, particularly a web server running Apache. To enable the VPN tunnel,
+we will use OpenVPN (https://openvpn.net).
+
+Figure 1 – Scenario for the Practical Assignment #1
+
+Regarding authentication, the two communication entities participating in the VPN tunnel (road warrior and the VPN
+gateway) should possess valid X.509 certificates, which are created with a private Certification Authority (CA). Users
+establishing remote connections to the VPN gateway (road warriors), as well as users connecting to the Apache server, will
+also use two-factor authentication, as described below. Apache must also implement client authentication via X.509
+certificates. Figure 2 provides an illustration of the interactions between all the entities involved in this setup.
+
+Figure 2 – X.509 mutual authentication and OCSP
+
+As we can observe in Figure 2, the VPN gateway and the Apache web server must verify the status of validity of certificates
+using OCSP (Online Certificate Status Protocol) and revocation information from the CA. OCSP verification in not
+required for the road warrior. Next, we describe the configuration requirements for the various components of the
+assignment.
+
+3. Configuration requirements
+VPN tunnel for remote access (road warriors)
+As illustrated in Figure 1, remote clients (road warriors) are able to connect to the Coimbra VPN gateway, and using the
+tunnel remotely access hosts in the Internal network. The following configuration requirements should be considered:
+•
+
+In order to establish a VPN tunnel with the Coimbra gateway, the road warrior must be in the possession of a valid
+X.509 certificate, issued by the private CA of the scenario.
+
+•
+
+The road warrior and the Coimbra VPN gateway must perform mutual authentication using X.509 digital certificates.
+
+•
+
+The Coimbra VPN gateway should verify the validity of the X.509 certificate presented by the road warrior using OCSP
+and, in case the certificate is revoked, the gateway should refuse the connection.
+
+•
+
+In order to authorize the remote user, the Coimbra gateway should also enforce two other authentication steps: the user
+must present a valid username and password, plus a one-time password (OTP, or an authentication token).
+
+Web server
+2
+
+The road warrior user should be able to contact the Apache web server with HTTPS through the VPN tunnel. The
+following configuration requirements should be considered:
+•
+
+Apache should enforce two-factor authentication in order to authorize accesses from clients: the client (browser) should
+present a valid X.509 certificate (issued with the private CA of the scenario) and the user should also present a valid onetime password (or authentication token).
+
+•
+
+As in the VPN, the validity of the X.509 certificate presented by the client should be checked in the CA using OCSP.
+
+Two-factor user authentication
+As previously discussed, VPN establishment and HTTPS accesses to Apache make use of one-time passwords
+(authentication tokens), which may be generated by an appropriate application. One-time passwords may be generated using
+the TOTP (Time-based One-time Password Algorithm). This algorithm employs a secret key shared between the user
+(client) and the remote service, plus a timestamp (obtained from the current system time), to obtain a one-time password.
+In order to generate a one-time password, the user may use an application such as Google Authenticator, illustrated in
+Figure 3. This application periodically generates a new one-time password that can be used to authenticate the user with the
+remote service. This application is available for iOS and Android 1.
+Certification authority
+As already discussed, the goal is to use OpenSSL to configure a private Certification Authority, as well as to issue and revoke
+X.509 digital certificates for the VPN gateways and remote users. The following configuration requirements should be
+considered:
+•
+
+The Certification Authority is used to issue certificates for the VPN gateway, VPN client and Apache web server.
+
+•
+
+The Certification Authority allows the revocation of certificates previously issued.
+
+•
+
+The Certification Authority also supports a OCSP responder.
+
+For Android: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en and
+for Apple iOS: https://itunes.apple.com/us/app/google-authenticator/id388497605?mt=8
+1
+
+3
+
+Figure 3 – Google Authenticator app, to generate a one-time password to access services enabled with two-factor authentication
+
+4. Delivery of the Practical Assignment
+With the assignment, please deliver also a report, containing the following information:
+•
+
+Descriptions of the configurations for the implementation of the previous requirements.
+
+•
+
+A description of how the private Certification Authority was created using OpenSSL.
+
+•
+
+A description of how X.509 certificates were issued and revoked using the private Certification Authority.
+
+•
+
+A description of the tests performed to validate the functionalities implemented.
+
+•
+
+Remaining information considered relevant.
+
+For the delivery of the assignment, put your report, as well as the relevant configuration files, in a single archive. This archive
+should be signed using your PGP key and encrypted using the PGP key of your PL teacher.
+Note: Assignments without PGP will be accepted, although with a discount of 5% in the final grade.
+Delivery deadline:
+•
+
+The deadline for the delivery of the assignment (configuration files and report) is May 3rd 2026.
+
+•
+
+Submission via Inforestudante.
+
+4
+
+