From d5566090c6be853e1c36298f6bd6ff31bcb26f56 Mon Sep 17 00:00:00 2001 From: Vasco Date: Tue, 21 Apr 2026 23:46:06 +0100 Subject: [PATCH] openssl --- VM_CONFIG.sh | 3 +- VM_OPENSSL.sh | 11 ++ VM_VPN_GATEWAY.sh | 9 ++ conf/client.conf | 2 - practical-assignment-2.pdf => enunciado.pdf | Bin enunciado.txt | 143 ++++++++++++++++++++ 6 files changed, 164 insertions(+), 4 deletions(-) rename practical-assignment-2.pdf => enunciado.pdf (100%) create mode 100644 enunciado.txt diff --git a/VM_CONFIG.sh b/VM_CONFIG.sh index 6ad4eee..b92ff4a 100755 --- a/VM_CONFIG.sh +++ b/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/ca.crt $CA_DIR +cp ca/serial "${CA_DIR}/serial" mkdir -p /etc/openvpn/server mkdir -p /etc/openvpn/client diff --git a/VM_OPENSSL.sh b/VM_OPENSSL.sh index 67daadf..1b4330d 100644 --- a/VM_OPENSSL.sh +++ b/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 & diff --git a/VM_VPN_GATEWAY.sh b/VM_VPN_GATEWAY.sh index 9d43f9d..461db38 100644 --- a/VM_VPN_GATEWAY.sh +++ b/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" diff --git a/conf/client.conf b/conf/client.conf index 6620368..6396df8 100644 --- a/conf/client.conf +++ b/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 diff --git a/practical-assignment-2.pdf b/enunciado.pdf similarity index 100% rename from practical-assignment-2.pdf rename to enunciado.pdf diff --git a/enunciado.txt b/enunciado.txt new file mode 100644 index 0000000..35be199 --- /dev/null +++ b/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 + + \ No newline at end of file