One place for hosting & domains

      How To Set Up a Firewall Using firewalld on CentOS 8


      Introduction

      firewalld is firewall management software available for many Linux distributions, which acts as a frontend for Linux’s in-kernel nftables or iptables packet filtering systems.

      In this guide, we will show you how to set up a firewalld firewall for your CentOS 8 server, and cover the basics of managing the firewall with the firewall-cmd administrative tool.

      Prerequisites

      To complete this tutorial, you will need a server running CentOS 8. We will assume you are logged into this server as a non-root, sudo-enabled user. To set this up, see our Initial Server Setup for CentOS 8 guide.

      Basic Concepts in firewalld

      Before we begin talking about how to actually use the firewall-cmd utility to manage your firewall configuration, we should get familiar with a few concepts that the tool introduces.

      Zones

      The firewalld daemon manages groups of rules using entities called zones. Zones are sets of rules that dictate what traffic should be allowed depending on the level of trust you have in the network. Network interfaces are assigned to a zone to dictate the behavior that the firewall should allow.

      For computers that might move between networks frequently (like laptops), this kind of flexibility provides a good method of changing your rules depending on your environment. You may have strict rules in place prohibiting most traffic when operating on a public WiFi network, while allowing more relaxed restrictions when connected to your home network. For a server, these zones are often not as important because the network environment rarely, if ever, changes.

      Regardless of how dynamic your network environment may be, it is still useful to be familiar with the general idea behind each of the predefined zones for firewalld. The predefined zones within firewalld are, in order from least trusted to most trusted:

      • drop: The lowest level of trust. All incoming connections are dropped without reply and only outgoing connections are possible.
      • block: Similar to the above, but instead of simply dropping connections, incoming requests are rejected with an icmp-host-prohibited or icmp6-adm-prohibited message.
      • public: Represents public, untrusted networks. You don’t trust other computers but may allow selected incoming connections on a case-by-case basis.
      • external: External networks in the event that you are using the firewall as your gateway. It is configured for NAT masquerading so that your internal network remains private but reachable.
      • internal: The other side of the external zone, used for the internal portion of a gateway. The computers are fairly trustworthy and some additional services are available.
      • dmz: Used for computers located in a DMZ (isolated computers that will not have access to the rest of your network). Only certain incoming connections are allowed.
      • work: Used for work machines. Trust most of the computers in the network. A few more services might be allowed.
      • home: A home environment. It generally implies that you trust most of the other computers and that a few more services will be accepted.
      • trusted: Trust all of the machines in the network. The most open of the available options and should be used sparingly.

      To use the firewall, we can create rules and alter the properties of our zones and then assign our network interfaces to whichever zones are most appropriate.

      Rule Permanence

      In firewalld, rules can be applied to the current runtime ruleset, or be made permanent. When a rule is added or modified, by default, only the currently running firewall is modified. After the next reboot – or reload of the firewalld service – only the permanent rules will remain.

      Most firewall-cmd operations can take a --permanent flag to indicate that the changes should be applied to the permenent configuration. Additionally, the currently running firewall can be saved to the permanent configuration with the firewall-cmd --runtime-to-permanent command.

      This separation of runtime vs permanent configuration means that you can safely test rules in your active firewall, then reload to start over if there are problems.

      Installing and Enabling firewalld

      firewalld is installed by default on some Linux distributions, including many images of CentOS 8. However, it may be necessary for you to install firewalld yourself:

      • sudo dnf install firewalld

      After you install firewalld, you can enable the service and reboot your server. Keep in mind that enabling firewalld will cause the service to start up at boot. It is best practice to create your firewall rules and take the opportunity to test them before configuring this behavior in order to avoid potential issues.

      • sudo systemctl enable firewalld
      • sudo systemctl start firewalld

      When the server restarts, your firewall should be brought up, your network interfaces should be put into the zones you configured (or fall back to the configured default zone), and any rules associated with the zone(s) will be applied to the associated interfaces.

      We can verify that the service is running and reachable by typing:

      • sudo firewall-cmd --state

      Output

      running

      This indicates that our firewall is up and running with the default configuration.

      Getting Familiar with the Current Firewall Rules

      Before we begin to make modifications, we should familiarize ourselves with the default environment and rules provided by firewalld.

      Exploring the Defaults

      We can see which zone is currently selected as the default by typing:

      • firewall-cmd --get-default-zone

      Output

      public

      Since we haven’t given firewalld any commands to deviate from the default zone, and none of our interfaces are configured to bind to another zone, that zone will also be the only active zone (the zone that is controlling the traffic for our interfaces). We can verify that by typing:

      • firewall-cmd --get-active-zones

      Output

      public interfaces: eth0 eth1

      Here, we can see that our example server has two network interfaces being controlled by the firewall (eth0 and eth1). They are both currently being managed according to the rules defined for the public zone.

      How do we know what rules are associated with the public zone though? We can print out the default zone’s configuration by typing:

      • sudo firewall-cmd --list-all

      Output

      public (active) target: default icmp-block-inversion: no interfaces: eth0 eth1 sources: services: cockpit dhcpv6-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:

      We can tell from the output that this zone is both the default and active, and that the eth0 and eth1 interfaces are associated with this zone (we already knew all of this from our previous inquiries). However, we can also see that this zone allows traffic for a DHCP client (for IP address assignment), SSH (for remote administration), and Cockpit (a web-based console).

      Exploring Alternative Zones

      Now we have a good idea about the configuration for the default and active zone. We can find out information about other zones as well.

      To get a list of the available zones, type:

      Output

      block dmz drop external home internal public trusted work

      We can see the specific configuration associated with a zone by including the --zone= parameter in our --list-all command:

      • sudo firewall-cmd --zone=home --list-all

      Output

      home target: default icmp-block-inversion: no interfaces: sources: services: cockpit dhcpv6-client mdns samba-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:

      You can output all of the zone definitions by using the --list-all-zones option. You will probably want to pipe the output into a pager for easier viewing:

      • sudo firewall-cmd --list-all-zones | less

      Next we will learn about assiging zones to network interfaces.

      Selecting Zones for your Interfaces

      Unless you have configured your network interfaces otherwise, each interface will be put in the default zone when the firewall is started.

      Changing the Zone of an Interface

      You can move an interface between zones during a session by using the --zone= parameter in combination with the --change-interface= parameter. As with all commands that modify the firewall, you will need to use sudo.

      For instance, we can move our eth0 interface to the home zone by typing this:

      • sudo firewall-cmd --zone=home --change-interface=eth0

      Output

      success

      Note: Whenever you are moving an interface to a new zone, be aware that you are probably modifying which services will be operational. For instance, here we are moving to the home zone, which has SSH available. This means that our connection shouldn’t drop. Some other zones do not have SSH enabled by default, and switching to one of these zones could cause your connection to drop, preventing you from logging back into your server.

      We can verify that this was successful by asking for the active zones again:

      • firewall-cmd --get-active-zones

      Output

      home interfaces: eth0 public interfaces: eth1

      Adjusting the Default Zone

      If all of your interfaces can be handled well by a single zone, it’s probably easiest to just designate the best zone as default and then use that for your configuration.

      You can change the default zone with the --set-default-zone= parameter. This will immediately change any interface using the default zone:

      • sudo firewall-cmd --set-default-zone=home

      Output

      success

      Setting Rules for your Applications

      Let’s run through the basic way of defining firewall exceptions for the services you wish to make available.

      Adding a Service to your Zones

      The most straighforward method is to add the services or ports you need to the zones you are using. You can get a list of the available service definitions with the --get-services option:

      • firewall-cmd --get-services

      Output

      RH-Satellite-6 amanda-client amanda-k5-client amqp amqps apcupsd audit bacula bacula-client bb bgp bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc bittorrent-lsd ceph ceph-mon cfengine cockpit condor-collector ctdb dhcp dhcpv6 dhcpv6-client distcc dns dns-over-tls docker-registry docker-swarm dropbox-lansync elasticsearch etcd-client etcd-server finger freeipa-4 freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master git grafana gre high-availability http https imap imaps ipp ipp-client ipsec irc ircs iscsi-target isns jenkins kadmin kdeconnect kerberos kibana klogin kpasswd kprop kshell ldap ldaps libvirt libvirt-tls lightning-network llmnr managesieve matrix mdns memcache minidlna mongodb mosh mountd mqtt mqtt-tls ms-wbt mssql murmur mysql nfs nfs3 nmea-0183 nrpe ntp nut openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole plex pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy prometheus proxy-dhcp ptp pulseaudio puppetmaster quassel radius rdp redis redis-sentinel rpc-bind rsh rsyncd rtsp salt-master samba samba-client samba-dc sane sip sips slp smtp smtp-submission smtps snmp snmptrap spideroak-lansync spotify-sync squid ssdp ssh steam-streaming svdrp svn syncthing syncthing-gui synergy syslog syslog-tls telnet tentacle tftp tftp-client tile38 tinc tor-socks transmission-client upnp-client vdsm vnc-server wbem-http wbem-https wsman wsmans xdmcp xmpp-bosh xmpp-client xmpp-local xmpp-server zabbix-agent zabbix-server

      Note: You can get more details about each of these services by looking at their associated .xml file within the /usr/lib/firewalld/services directory. For instance, the SSH service is defined like this:

      /usr/lib/firewalld/services/ssh.xml

      <?xml version="1.0" encoding="utf-8"?>
      <service>
        <short>SSH</short>
        <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description>
        <port protocol="tcp" port="22"/>
      </service>
      

      You can enable a service for a zone using the --add-service= parameter. The operation will target the default zone or whatever zone is specified by the --zone= parameter. By default, this will only adjust the current firewall session. You can adjust the permanent firewall configuration by including the --permanent flag.

      For instance, if we are running a web server serving conventional HTTP traffic, we can temporarily allow this traffic for interfaces in our public zone by typing:

      • sudo firewall-cmd --zone=public --add-service=http

      You can leave out the --zone= flag if you wish to modify the default zone. We can verify the operation was successful by using the --list-all or --list-services operations:

      • sudo firewall-cmd --zone=public --list-services

      Output

      cockpit dhcpv6-client http ssh

      Once you have tested that everything is working as it should, you will probably want to modify the permanent firewall rules so that your service will still be available after a reboot. We can make our previous change permanent by retyping it and adding the --permanent flag:

      • sudo firewall-cmd --zone=public --add-service=http --permanent

      Output

      success

      Alternately, you could use the --runtime-to-permanent flag to save the currently running firewall configuration to the permanant config:

      • sudo firewall-cmd --runtime-to-permanent

      Be careful with this, as all changes made to the running firewall will be commited permenantly.

      Whichever method you chose, you can verify that it was successful by adding the --permanent flag to the --list-services operation. You need to use sudo for any --permanent operations:

      • sudo firewall-cmd --zone=public --list-services --permanent

      Output

      cockpit dhcpv6-client http ssh

      Your public zone will now allow HTTP web traffic on port 80. If your web server is configured to use SSL/TLS, you’ll also want to add the https service. We can add that to the current session and the permanent rule-set by typing:

      • sudo firewall-cmd --zone=public --add-service=https
      • sudo firewall-cmd --zone=public --add-service=https --permanent

      What If No Appropriate Service Is Available?

      The services that are included with the firewalld installation represent many of the most common applications that you may wish to allow access to. However, there will likely be scenarios where these services do not fit your requirements.

      In this situation, you have two options.

      Opening a Port for your Zones

      The easiest way to add support for your specific application is to open up the ports that it uses in the appropriate zone(s). This is done by specifying the port or port range, and the associated protocol (TCP or UDP) for the ports.

      For instance, if our application runs on port 5000 and uses TCP, we could temporarily add this to the public zone using the --add-port= parameter. Protocols can be designated as either tcp or udp:

      • sudo firewall-cmd --zone=public --add-port=5000/tcp

      Output

      success

      We can verify that this was successful using the --list-ports operation:

      • sudo firewall-cmd --zone=public --list-ports

      Output

      5000/tcp

      It is also possible to specify a sequential range of ports by separating the beginning and ending port in the range with a dash. For instance, if our application uses UDP ports 4990 to 4999, we could open these up on public by typing:

      • sudo firewall-cmd --zone=public --add-port=4990-4999/udp

      After testing, we would likely want to add these to the permanent firewall. Use sudo firewall-cmd --runtime-to-permanent to do that, or rerun the commands with the --permanent flag:

      • sudo firewall-cmd --zone=public --permanent --add-port=5000/tcp
      • sudo firewall-cmd --zone=public --permanent --add-port=4990-4999/udp
      • sudo firewall-cmd --zone=public --permanent --list-ports

      Output

      success success 5000/tcp 4990-4999/udp

      Defining a Service

      Opening ports for your zones is a straightforward solution, but it can be difficult to keep track of what each one is for. If you ever decommission a service on your server, you may have a hard time remembering which ports that have been opened are still required. To avoid this situation, it is possible to define a new service.

      Services are collections of ports with an associated name and description. Using services is easier to administer than ports, but requires a bit of up-front work. The easiest way to start is to copy an existing script (found in /usr/lib/firewalld/services) to the /etc/firewalld/services directory where the firewall looks for non-standard definitions.

      For instance, we could copy the SSH service definition to use for our example service definition like this. The filename minus the .xml suffix will dictate the name of the service within the firewall services list:

      • sudo cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/example.xml

      Now, you can adjust the definition found in the file you copied. First open it in your favorite text editor. We’ll use vi here:

      • sudo vi /etc/firewalld/services/example.xml

      To start, the file will contain the SSH definition that you copied:

      /etc/firewalld/services/example.xml

      <?xml version="1.0" encoding="utf-8"?>
      <service>
        <short>SSH</short>
        <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description>
        <port protocol="tcp" port="22"/>
      </service>
      

      The majority of this definition is actually metadata. You will want to change the short name for the service within the <short> tags. This is a human-readable name for your service. You should also add a description so that you have more information if you ever need to audit the service. The only configuration you need to make that actually affects the functionality of the service will likely be the port definition where you identify the port number and protocol you wish to open. Multiple <port/> tags can be specified.

      For our example service, imagine that we need to open up port 7777 for TCP and 8888 for UDP. We can modify the existing definition with something like this:

      /etc/firewalld/services/example.xml

      <?xml version="1.0" encoding="utf-8"?>
      <service>
        <short>Example Service</short>
        <description>This is just an example service. It probably shouldn't be used on a real system.</description>
        <port protocol="tcp" port="7777"/>
        <port protocol="udp" port="8888"/>
      </service>
      

      Save and close the file.

      Reload your firewall to get access to your new service:

      • sudo firewall-cmd --reload

      You can see that it is now among the list of available services:

      • firewall-cmd --get-services

      Output

      RH-Satellite-6 amanda-client amanda-k5-client amqp amqps apcupsd audit bacula bacula-client bb bgp bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc bittorrent-lsd ceph ceph-mon cfengine cockpit condor-collector ctdb dhcp dhcpv6 dhcpv6-client distcc dns dns-over-tls docker-registry docker-swarm dropbox-lansync elasticsearch etcd-client etcd-server example finger freeipa-4 freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master git grafana gre high-availability http https imap imaps ipp ipp-client ipsec irc ircs iscsi-target isns jenkins kadmin kdeconnect kerberos kibana klogin kpasswd kprop kshell ldap ldaps libvirt libvirt-tls lightning-network llmnr managesieve matrix mdns memcache minidlna mongodb mosh mountd mqtt mqtt-tls ms-wbt mssql murmur mysql nfs nfs3 nmea-0183 nrpe ntp nut openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole plex pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy prometheus proxy-dhcp ptp pulseaudio puppetmaster quassel radius rdp redis redis-sentinel rpc-bind rsh rsyncd rtsp salt-master samba samba-client samba-dc sane sip sips slp smtp smtp-submission smtps snmp snmptrap spideroak-lansync spotify-sync squid ssdp ssh steam-streaming svdrp svn syncthing syncthing-gui synergy syslog syslog-tls telnet tentacle tftp tftp-client tile38 tinc tor-socks transmission-client upnp-client vdsm vnc-server wbem-http wbem-https wsman wsmans xdmcp xmpp-bosh xmpp-client xmpp-local xmpp-server zabbix-agent zabbix-server

      You can now use this service in your zones as you normally would.

      Creating Your Own Zones

      While the predefined zones will probably be more than enough for most users, it can be helpful to define your own zones that are more descriptive of their function.

      For instance, you might want to create a zone for your web server, called publicweb. However, you might want to have another zone configured for the DNS service you provide on your private network. You might want a zone called “privateDNS” for that.

      When adding a zone, you must add it to the permanent firewall configuration. You can then reload to bring the configuration into your running session. For instance, we could create the two zones we discussed above by typing:

      • sudo firewall-cmd --permanent --new-zone=publicweb
      • sudo firewall-cmd --permanent --new-zone=privateDNS

      You can verify that these are present in your permanent configuration by typing:

      • sudo firewall-cmd --permanent --get-zones

      Output

      block dmz drop external home internal privateDNS public publicweb trusted work

      As stated before, these won’t be available in the runtime firewall yet:

      Output

      block dmz drop external home internal public trusted work

      Reload the firewall to bring these new zones into the active runtime configuration:

      • sudo firewall-cmd --reload
      • firewall-cmd --get-zones

      Output

      block dmz drop external home internal privateDNS public publicweb trusted work

      Now, you can begin assigning the appropriate services and ports to your zones. It’s usually a good idea to adjust the runtime firewall and then save those changes to the permanent configuration after testing. For instance, for the publicweb zone, you might want to add the SSH, HTTP, and HTTPS services:

      • sudo firewall-cmd --zone=publicweb --add-service=ssh
      • sudo firewall-cmd --zone=publicweb --add-service=http
      • sudo firewall-cmd --zone=publicweb --add-service=https
      • sudo firewall-cmd --zone=publicweb --list-all

      Output

      publicweb target: default icmp-block-inversion: no interfaces: sources: services: http https ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:

      Likewise, we can add the DNS service to our privateDNS zone:

      • sudo firewall-cmd --zone=privateDNS --add-service=dns
      • sudo firewall-cmd --zone=privateDNS --list-all

      Output

      privateDNS target: default icmp-block-inversion: no interfaces: sources: services: dns ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:

      We could then change our interfaces over to these new zones to test them out:

      • sudo firewall-cmd --zone=publicweb --change-interface=eth0
      • sudo firewall-cmd --zone=privateDNS --change-interface=eth1

      At this point, you have the opportunity to test your configuration. If these values work for you, you will want to add these rules to the permanent configuration. You could do that by running all the commands again with the --permanent flag appended, but in this case we’ll use the --runtime-to-permanent flag to save our entire runtime configuration permanently:

      • sudo firewall-cmd --runtime-to-permanent

      After permanently applying these rules, reload the firewall to test that the changes remain:

      • sudo firewall-cmd --reload

      Validate that the correct zones were assigned:

      • firewall-cmd --get-active-zones

      Output

      privateDNS interfaces: eth1 publicweb interfaces: eth0

      And validate that the appropriate services are available for both of the zones:

      • sudo firewall-cmd --zone=publicweb --list-services

      Output

      http https ssh
      • sudo firewall-cmd --zone=privateDNS --list-services

      Output

      dns

      You have successfully set up your own zones! If you want to make one of these zones the default for other interfaces, remember to configure that behavior with the --set-default-zone= parameter:

      • sudo firewall-cmd --set-default-zone=publicweb

      Conclusion

      You should now have a fairly thorough understanding of how to administer the firewalld service on your CentOS system for day-to-day use.

      The firewalld service allows you to configure maintainable rules and rule-sets that take into consideration your network environment. It allows you to seamlessly transition between different firewall policies through the use of zones and gives administrators the ability to abstract the port management into more friendly service definitions. Acquiring a working knowledge of this system will allow you to take advantage of the flexibility and power that this tool provides.

      For more information on firewalld, please see the official firewalld documentation.



      Source link

      How To Set Up and Configure a Certificate Authority (CA) On CentOS 8


      Introduction

      A Certificate Authority (CA) is an entity responsible for issuing digital certificates to verify identities on the internet. Although public CAs are a popular choice for verifying the identity of websites and other services that are provided to the general public, private CAs are typically used for closed groups and private services.

      Building a private Certificate Authority will enable you to configure, test, and run programs that require encrypted connections between a client and a server. With a private CA, you can issue certificates for users, servers, or individual programs and services within your infrastructure.

      Some examples of programs on Linux that use their own private CA are OpenVPN and Puppet . You can also configure your web server to use certificates issued by a private CA in order to make development and staging environments match production servers that use TLS to encrypt connections.

      In this guide, we’ll learn how to set up a private Certificate Authority on a CentOS 8 server, and how to generate and sign a testing certificate using your new CA. You will also learn how to import the CA server’s public certificate into your operating system’s certificate store so that you can verify the chain of trust between the CA and remote servers or users. Finally you will learn how to revoke certificates and distribute a Certificate Revocation List to make sure only authorized users and systems can use services that rely on your CA.

      Prerequisites

      To follow this tutorial, you will need a CentOS 8 server with a sudo enabled, non-root user, and a firewall set up with firewalld. You can follow our Initial Server Setup with CentOS 8 guide to complete that set up.

      This server will be referred to as the CA Server in this tutorial.

      Ensure that the CA Server is a standalone system. It will only be used to import, sign, and revoke certificate requests. It should not run any other services, and ideally it will be offline or completely shut down when you are not actively working with your CA.

      Note: The last section of this tutorial is optional if you would like to learn about signing and revoking certificates. If you choose to complete those practice steps, you will need a second CentOS 8 server or you can also use your own local Linux computer running CentOS 8, Fedora or a RedHat derivative.

      Step 1 — Installing Easy-RSA

      The first task in this tutorial is to install the easy-rsa set of scripts on your CA Server. easy-rsa is a Certificate Authority management tool that you will use to generate a private key, and public root certificate, which you will then use to sign requests from clients and servers that will rely on your CA.

      The easy-rsa package is not available by default in CentOS 8, so you will need to enable the Extra Packages for Enterprise Linux (EPEL) repository. EPEL is managed by the Fedora Project and contains non-standard but popular packages for Fedora, CentOS, and other Linux distributions that use the RPM package format. Login to your CA Server as the non-root sudo user that you created during the initial setup steps and run the following:

      • sudo dnf install epel-release

      You will be prompted to download the package and install it. Press y to confirm you want to install the package.

      Now install the easy-rsa package, again entering y at the prompt:

      • sudo dnf install easy-rsa

      At this point you have everything you need set up and ready to use Easy-RSA. In the next step you will create a Public Key Infrastructure, and then start building your Certificate Authority.

      Step 2 — Preparing a Public Key Infrastructure Directory

      Now that you have installed easy-rsa, it is time to create a skeleton Public Key Infrastructure (PKI) on the CA Server. Ensure that you are still logged in as your non-root user and create an easy-rsa directory. Make sure that you do not use sudo to run any of the following commands, since your normal user should manage and interact with the CA without elevated privileges.

      This will create a new directory called easy-rsa in your home folder. We’ll use this directory to create symbolic links pointing to the easy-rsa package files that we’ve installed in the previous step. These files are located in the /usr/share/easy-rsa/3 folder on the CA Server.

      Create the symlinks with the ln command:

      • ln -s /usr/share/easy-rsa/3/* ~/easy-rsa/

      Note: While other guides might instruct you to copy the easy-rsa package files into your PKI directory, this tutorial adopts a symlink approach. As a result, any updates to the easy-rsa package will be automatically reflected in your PKI’s scripts.

      To restrict access to your new PKI directory, ensure that only the owner can access it using the chmod command:

      • chmod 700 /home/sammy/easy-rsa

      Finally, initialize the PKI inside the easy-rsa directory:

      • cd ~/easy-rsa
      • ./easyrsa init-pki

      Output

      init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/sammy/easy-rsa/pki

      After completing this section you have a directory that contains all the files that are needed to create a Certificate Authority. In the next section you will create the private key and public certificate for your CA.

      Step 3 — Creating a Certificate Authority

      Before you can create your CA’s private key and certificate, you need to create and populate a file called vars with some default values. First you will cd into the easy-rsa directory, then you will create and edit the vars file with nano or your preferred text editor.

      The default text editor that comes with CentOS 8 is vi. vi is an extremely powerful text editor, but it can be somewhat obtuse for users who lack experience with it. You might want to install a more user-friendly editor such as nano to facilitate editing configuration files on your CentOS 8 server:

      When you are prompted to install nano enter y to continue with the installation steps. Now you are ready to edit the vars file:

      Once the file is opened, paste in the following lines and edit each highlighted value to reflect your own organization info. The important part here is to ensure that you do not leave any of the values blank:

      ~/easy-rsa/vars

      set_var EASYRSA_REQ_COUNTRY "US" set_var EASYRSA_REQ_PROVINCE "NewYork" set_var EASYRSA_REQ_CITY "New York City" set_var EASYRSA_REQ_ORG "DigitalOcean" set_var EASYRSA_REQ_EMAIL "admin@example.com" set_var EASYRSA_REQ_OU "Community"

      When you are finished, save and close the file. If you are using nano, you can do so by pressing CTRL+X, then Y and ENTER to confirm. You are now ready to build your CA.

      To create the root public and private key pair for your Certificate Authority, run the ./easy-rsa command again, this time with the build-ca option:

      In the output, you’ll see some lines about the OpenSSL version and you will be prompted to enter a passphrase for your key pair. Be sure to choose a strong passphrase, and note it down somewhere safe. You will need to input the passphrase any time that you need to interact with your CA, for example to sign or revoke a certificate.

      You will also be asked to confirm the Common Name (CN) for your CA. The CN is the name used to refer to this machine in the context of the Certificate Authority. You can enter any string of characters for the CA’s Common Name but for simplicity’s sake, press ENTER to accept the default name.

      Output

      . . . Enter New CA Key Passphrase: Re-Enter New CA Key Passphrase: . . . Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/sammy/easy-rsa/pki/ca.crt

      Note: If you don’t want to be prompted for a password every time you interact with your CA, you can run the build-ca command with the nopass option, like this:

      • ./easyrsa build-ca nopass

      You now have two important files — ~/easy-rsa/pki/ca.crt and ~/easy-rsa/pki/private/ca.key — which make up the public and private components of a Certificate Authority.

      • ca.crt is the CA’s public certificate file. Users, servers, and clients will use this certificate to verify that they are part of the same web of trust. Every user and server that uses your CA will need to have a copy of this file. All parties will rely on the public certificate to ensure that someone is not impersonating a system and performing a Man-in-the-middle attack.

      • ca.key is the private key that the CA uses to sign certificates for servers and clients. If an attacker gains access to your CA and, in turn, your ca.key file, you will need to destroy your CA. This is why your ca.key file should only be on your CA machine and that, ideally, your CA machine should be kept offline when not signing certificate requests as an extra security measure.

      With that, your CA is in place and it is ready to be used to sign certificate requests, and to revoke certificates.

      Step 4 — Distributing your Certificate Authority’s Public Certificate

      Now your CA is configured and ready to act as a root of trust for any systems that you want to configure to use it. You can add the CA’s certificate to your OpenVPN servers, web servers, mail servers, and so on. Any user or server that needs to verify the identity of another user or server in your network should have a copy of the ca.crt file imported into their operating system’s certificate store.

      To import the CA’s public certificate into a second Linux system like another server or a local computer, first obtain a copy of the ca.crt file from your CA server. You can use the cat command to output it in a terminal, and then copy and paste it into a file on the second computer that is importing the certificate. You can also use tools like scp, rsync to transfer the file between systems. However we’ll use copy and paste with nano in this step since it will work on all systems.

      As your non-root user on the CA Server, run the following command:

      • cat ~/easy-rsa/pki/ca.crt

      There will be output in your terminal that is similar to the following:

      Output

      -----BEGIN CERTIFICATE----- MIIDSzCCAjOgAwIBAgIUcR9Crsv3FBEujrPZnZnU4nSb5TMwDQYJKoZIhvcNAQEL BQAwFjEUMBIGA1UEAwwLRWFzeS1SU0EgQ0EwHhcNMjAwMzE4MDMxNjI2WhcNMzAw . . . . . . -----END CERTIFICATE-----

      Copy everything, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines and the dashes.

      On your second Linux system use nano or your preferred text editor to open a file called /tmp/ca.crt:

      Paste the contents that you just copied from the CA Server into the editor. When you are finished, save and close the file. If you are using nano, you can do so by pressing CTRL+X, then Y and ENTER to confirm.

      Now that you have a copy of the ca.crt file on your second Linux system, it is time to import the certificate into its operating system certificate store.

      On CentOS, Fedora, or other RedHat derived Linux systems run the following commands to import the certificate:

      CentOS, Fedora, RedHat distributions

      • sudo cp /tmp/ca.crt /etc/pki/ca-trust/source/anchors/
      • update-ca-trust

      To import the CA Server’s certificate on a Debian or Ubuntu based system, copy and paste the file contents onto the system just like in the previous example in a file called /tmp/ca.crt. Next, copy the certificate into /usr/local/share/ca-certificates/, then run the update-ca-certificates command.

      Debian and Ubuntu derived distributions

      • sudo cp /tmp/ca.crt /usr/local/share/ca-certificates/
      • update-ca-certificates

      Now your second Linux system will trust any certificate that has been signed by the CA server.

      Note: If you are using your CA with web servers and use Firefox as a browser you will need to import the public ca.crt certificate into Firefox directly. Firefox does not use the local operating system’s certificate store. For details on how to add your CA’s certificate to Firefox please see this support article from Mozilla on Setting Up Certificate Authorities (CAs) in Firefox.

      If you are using your CA to integrate with a Windows environment or desktop computers, please see the documentation on how to use certutil.exe to install a CA certificate.

      If you are using this tutorial as a prerequisite for another tutorial, or are familiar with how to sign and revoke certificates you can stop here. If you would like to learn more about how to sign and revoke certificates, then the following optional section will explain each process in detail.

      (Optional) — Creating Certificate Signing Requests and Revoking Certificates

      The following sections of the tutorial are optional. If you have completed all the previous steps then you have a fully configured and working Certificate Authority that you can use as a prerequisite for other tutorials. You can import your CA’s ca.crt file and verify certificates in your network that have been signed by your CA.

      If you would like to practice and learn more about how to sign certificate requests, and how to revoke certificates, then these optional sections will explain how both processes work.

      (Optional) — Creating and Signing a Practice Certificate Request

      Now that you have a CA ready to use, you can practice generating a private key and certificate request to get familiar with the signing and distribution process.

      A Certificate Signing Request (CSR) consists of three parts: a public key, identifying information about the requesting system, and a signature of the request itself, which is created using the requesting party’s private key. The private key will be kept secret, and will be used to encrypt information that anyone with the signed public certificate can then decrypt.

      The following steps will be run on your second Linux system running CentOS, Fedora, or another RedHat derived Linux distribution. It can be another remote server, or a local Linux machine like a laptop or a desktop computer. Since easy-rsa is not available by default on all systems, we’ll use the openssl tool to create a practice private key and certificate.

      openssl is usually installed by default on most Linux distributions, but just to be certain, run the following on your system:

      When you are prompted to install openssl enter y to continue with the installation steps. Now you are ready to create a practice CSR with openssl.

      The first step that you need to complete to create a CSR is generating a private key. To create a private key using openssl, create a practice-csr directory and then generate a key inside it. We will make this request for a fictional server called sammy-server, as opposed to creating a certificate that is used to identify a user or another CA.

      • mkdir ~/practice-csr
      • cd ~/practice-csr
      • openssl genrsa -out sammy-server.key

      Output

      Generating RSA private key, 2048 bit long modulus (2 primes) . . . . . . e is 65537 (0x010001)

      Now that you have a private key you can create a corresponding CSR, again using the openssl utility. You will be prompted to fill out a number of fields like Country, State, and City. You can enter a . if you’d like to leave a field blank, but be aware that if this were a real CSR, it is best to use the correct values for your location and organization:

      • openssl req -new -key sammy-server.key -out sammy-server.req

      Output

      . . . ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:New York Locality Name (eg, city) [Default City]:New York City Organization Name (eg, company) [Default Company Ltd]:DigitalOcean Organizational Unit Name (eg, section) []:Community Common Name (eg, your name or your server's hostname) []:sammy-server Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

      If you would like to automatically add those values as part of the openssl invocation instead of via the interactive prompt, you can pass the -subj argument to OpenSSL. Be sure to edit the highlighted values to match your practice location, organization, and server name:

      • openssl req -new -key sammy-server.key -out sammy-server.req -subj
      • /C=US/ST=New York/L=New York City/O=DigitalOcean/OU=Community/CN=sammy-server

      To verify the contents of a CSR, you can read in a request file with openssl and examine the fields inside:

      • openssl req -in sammy-server.req -noout -subject

      Output

      subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server

      Once you’re happy with the subject of your practice certificate request, copy the sammy-server.req file to your CA server using scp:

      • scp sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req

      In this step you generated a Certificate Signing Request for a fictional server called sammy-server. In a real-world scenario, the request could be from something like a staging or development web server that needs a TLS certificate for testing; or it could come from an OpenVPN server that is requesting a certificate so that users can connect to a VPN. In the next step, we’ll proceed to signing the certificate signing request using the CA Server’s private key.

      (Optional) — Signing a CSR

      In the previous step, you created a practice certificate request and key for a fictional server. You copied it to the /tmp directory on your CA server, emulating the process that you would use if you had real clients or servers sending you CSR requests that need to be signed.

      Continuing with the fictional scenario, now the CA Server needs to import the practice certificate and sign it. Once a certificate request is validated by the CA and relayed back to a server, clients that trust the Certificate Authority will also be able to trust the newly issued certificate.

      Since we will be operating inside the CA’s PKI where the easy-rsa utility is available, the signing steps will use the easy-rsa utility to make things easier, as opposed to using the openssl directly like we did in the previous example.

      The first step to sign the fictional CSR is to import the certificate request using the easy-rsa script:

      • cd ~/easy-rsa
      • ./easyrsa import-req /tmp/sammy-server.req sammy-server

      Output

      . . . The request has been successfully imported with a short name of: sammy-server You may now use this name to perform signing operations on this request.

      Now you can sign the request by running the easyrsa script with the sign-req option, followed by the request type and the Common Name that is included in the CSR. The request type can either be one of client, server, or ca. Since we’re practicing with a certificate for a fictional server, be sure to use the server request type:

      • ./easyrsa sign-req server sammy-server

      In the output, you’ll be asked to verify that the request comes from a trusted source. Type yes then press ENTER to confirm this:

      Output

      You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 3650 days: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes . . . Certificate created at: /home/sammy/easy-rsa/pki/issued/sammy-server.crt

      If you encrypted your CA key, you’ll be prompted for your password at this point.

      With those steps complete, you have signed the sammy-server.req CSR using the CA Server’s private key in /home/sammy/easy-rsa/pki/private/ca.key. The resulting sammy-server.crt file contains the practice server’s public encryption key, as well as a new signature from the CA Server. The point of the signature is to tell anyone who trusts the CA that they can also trust the sammy-server certificate.

      If this request was for a real server like a web server or VPN server, the last step on the CA Server would be to distribute the new sammy-server.crt and ca.crt files from the CA Server to the remote server that made the CSR request:

      • scp pki/issued/sammy-server.crt sammy@your_server_ip:/tmp
      • scp pki/ca.crt sammy@your_server_ip:/tmp

      At this point, you would be able to use the issued certificate with something like a web server, a VPN, configuration management tool, database system, or for client authentication purposes.

      (Optional) — Revoking a Certificate

      Occasionally, you may need to revoke a certificate to prevent a user or server from using it. Perhaps someone’s laptop was stolen, a web server was compromised, or an employee or contractor has left your organization.

      To revoke a certificate, the general process follows these steps:

      1. Revoke the certificate with the ./easyrsa revoke client_name command.
      2. Generate a new CRL with the ./easyrsa gen-crl command.
      3. Transfer the updated crl.pem file to the server or servers that rely on your CA, and on those systems copy it to the required directory or directories for programs that refer to it.
      4. Restart any services that use your CA and the CRL file.

      You can use this process to revoke any certificates that you’ve previously issued at any time. We’ll go over each step in detail in the following sections, starting with the revoke command.

      Revoking a Certificate

      To revoke a certificate, navigate to the easy-rsa directory on your CA server:

      Next, run the easyrsa script with the revoke option, followed by the client name you wish to revoke. Following the practice example above, the Common Name of the certificate is sammy-server:

      • ./easyrsa revoke sammy-server

      This will ask you to confirm the revocation by entering yes:

      Output

      Please confirm you wish to revoke the certificate with the following subject: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Continue with revocation: yes . . . Revoking Certificate 8348B3F146A765581946040D5C4D590A . . .

      Note the highlighted value on the Revoking Certificate line. This value is the unique serial number of the certificate that is being revoked. If you want to examine the revocation list in the last step of this section to verify that the certificate is in it, you’ll need this value.

      After confirming the action, the CA will revoke the certificate. However, remote systems that rely on the CA have no way to check whether any certificates have been revoked. Users and servers will still be able to use the certificate until the CA’s Certificate Revocation List (CRL) is distributed to all systems that rely on the CA.

      In the next step you’ll generate a CRL or update an existing crl.pem file.

      Generating a Certificate Revocation List

      Now that you have revoked a certificate, it is important to update the list of revoked certificates on your CA server. Once you have an updated revocation list you will be able to tell which users and systems have valid certificates in your CA.

      To generate a CRL, run the easy-rsa command with the gen-crl option while still inside the ~/easy-rsa directory:

      If you have used a passphrase when creating your ca.key file, you will be prompted to enter it. The gen-crl command will generate a file called crl.pem, containing the updated list of revoked certificates for that CA.

      Next you’ll need to transfer the updated crl.pem file to all servers and clients that rely on this CA each time you run the gen-crl command. Otherwise, clients and systems will still be able to access services and systems that use your CA, since those services need to know about the revoked status of the certificate.

      Transferring a Certificate Revocation List

      Now that you have generated a CRL on your CA server, you need to transfer it to remote systems that rely on your CA. To transfer this file to your servers, you can use the scp command.

      Note: This tutorial explains how to generate and distribute a CRL manually. While there are more robust and automated methods to distribute and check revocation lists like OCSP-Stapling, configuring those methods is beyond the scope of this article.

      Ensure you are logged into your CA server as your non-root user and run the following, substituting in your own server IP or DNS name in place of your_server_ip:

      • scp ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp

      Now that the file is on the remote system, the last step is to update any services with the new copy of the revocation list.

      Updating Services that Support a CRL

      Listing the steps that you need to use to update services that use the crl.pem file is beyond the scope of this tutorial. In general you will need to copy the crl.pem file into the location that the service expects and then restart it using systemctl.

      Once you have updated your services with the new crl.pem file, your services will be able to reject connections from clients or servers that are using a revoked certificate.

      Examining and Verifying the Contents of a CRL

      If you would like to examine a CRL file, for example to confirm a list of revoked certificates, use the following openssl command from within your easy-rsa directory on your CA server:

      • cd ~/easy-rsa
      • openssl crl -in pki/crl.pem -noout -text

      You can also run this command on any server or system that has the openssl tool installed with a copy of the crl.pem file. For example, if you transferred the crl.pem file to your second system and want to verify that the sammy-server certificate is revoked, you can use an openssl command like the following, substituting the serial number that you noted earlier when you revoked the certificate in place of the highlighted one here:

      • openssl crl -in /tmp/crl.pem -noout -text |grep -A 1 8348B3F146A765581946040D5C4D590A

      Output

      Serial Number: 8348B3F146A765581946040D5C4D590A Revocation Date: Apr 1 20:48:02 2020 GMT

      Notice how the grep command is used to check for the unique serial number that you noted in the revocation step. Now you can verify the contents of your Certificate Revocation List on any system that relies on it to restrict access to users and services.

      Conclusion

      In this tutorial you created a private Certificate Authority using the Easy-RSA package on a standalone CentOS 8 server. You learned how the trust model works between parties that rely on the CA. You also created and signed a Certificate Signing Request (CSR) for a practice server and then learned how to revoke a certificate. Finally, you learned how to generate and distribute a Certificate Revocation List (CRL) for any system that relies on your CA to ensure that users or servers that should not access services are prevented from doing so.

      Now you can issue certificates for users and use them with services like OpenVPN. You can also use your CA to configure development and staging web servers with certificates to secure your non-production environments. Using a CA with TLS certificates during development can help ensure that your code and environments match your production environment as closely as possible.

      If you would like to learn more about how to use OpenSSL, our OpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRs tutorial has lots of additional information to help you become more familiar with OpenSSL fundamentals.



      Source link

      How To Set Up and Configure a Certificate Authority (CA) On Debian 10


      Introduction

      A Certificate Authority (CA) is an entity responsible for issuing digital certificates to verify identities on the internet. Although public CAs are a popular choice for verifying the identity of websites and other services that are provided to the general public, private CAs are typically used for closed groups and private services.

      Building a private Certificate Authority will enable you to configure, test, and run programs that require encrypted connections between a client and a server. With a private CA, you can issue certificates for users, servers, or individual programs and services within your infrastructure.

      Some examples of programs on Linux that use their own private CA are OpenVPN and Puppet . You can also configure your web server to use certificates issued by a private CA in order to make development and staging environments match production servers that use TLS to encrypt connections.

      In this guide, we’ll learn how to set up a private Certificate Authority on a Debian 10 server, and how to generate and sign a testing certificate using your new CA. You will also learn how to import the CA server’s public certificate into your operating system’s certificate store so that you can verify the chain of trust between the CA and remote servers or users. Finally you will learn how to revoke certificates and distribute a Certificate Revocation List to make sure only authorized users and systems can use services that rely on your CA.

      Prerequisites

      To complete this tutorial, you will need access to a Debian 10 server to host your OpenVPN service. You will need to configure a non-root user with sudo privileges before you start this guide. You can follow our Debian 10 initial server setup guide to set up a user with appropriate permissions. The linked tutorial will also set up a firewall, which is assumed to be in place throughout this guide.

      This server will be referred to as the CA Server in this tutorial.

      Ensure that the CA Server is a standalone system. It will only be used to import, sign, and revoke certificate requests. It should not run any other services, and ideally it will be offline or completely shut down when you are not actively working with your CA.

      Note: The last section of this tutorial is optional if you would like to learn about signing and revoking certificates. If you choose to complete those practice steps, you will need a second Debian 10 server or you can also use your own local Linux computer running Debian or Ubuntu, or distributions derived from either of those.

      Step 1 — Installing Easy-RSA

      The first task in this tutorial is to install the easy-rsa set of scripts on your CA Server. easy-rsa is a Certificate Authority management tool that you will use to generate a private key, and public root certificate, which you will then use to sign requests from clients and servers that will rely on your CA.

      Login to your CA Server as the non-root sudo user that you created during the initial setup steps and run the following:

      • sudo apt update
      • sudo apt install easy-rsa

      You will be prompted to download the package and install it. Press y to confirm you want to install the package.

      At this point you have everything you need set up and ready to use Easy-RSA. In the next step you will create a Public Key Infrastructure, and then start building your Certificate Authority.

      Step 2 — Preparing a Public Key Infrastructure Directory

      Now that you have installed easy-rsa, it is time to create a skeleton Public Key Infrastructure (PKI) on the CA Server. Ensure that you are still logged in as your non-root user and create an easy-rsa directory. Make sure that you do not use sudo to run any of the following commands, since your normal user should manage and interact with the CA without elevated privileges.

      This will create a new directory called easy-rsa in your home folder. We’ll use this directory to create symbolic links pointing to the easy-rsa package files that we’ve installed in the previous step. These files are located in the /usr/share/easy-rsa folder on the CA Server.

      Create the symlinks with the ln command:

      • ln -s /usr/share/easy-rsa/* ~/easy-rsa/

      Note: While other guides might instruct you to copy the easy-rsa package files into your PKI directory, this tutorial adopts a symlink approach. As a result, any updates to the easy-rsa package will be automatically reflected in your PKI’s scripts.

      To restrict access to your new PKI directory, ensure that only the owner can access it using the chmod command:

      • chmod 700 /home/sammy/easy-rsa

      Finally, initialize the PKI inside the easy-rsa directory:

      • cd ~/easy-rsa
      • ./easyrsa init-pki

      Output

      init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/sammy/easy-rsa/pki

      After completing this section you have a directory that contains all the files that are needed to create a Certificate Authority. In the next section you will create the private key and public certificate for your CA.

      Step 3 — Creating a Certificate Authority

      Before you can create your CA’s private key and certificate, you need to create and populate a file called vars with some default values. First you will cd into the easy-rsa directory, then you will create and edit the vars file with nano or your preferred text editor:

      Once the file is opened, paste in the following lines and edit each highlighted value to reflect your own organization info. The important part here is to ensure that you do not leave any of the values blank:

      ~/easy-rsa/vars

      set_var EASYRSA_REQ_COUNTRY "US" set_var EASYRSA_REQ_PROVINCE "NewYork" set_var EASYRSA_REQ_CITY "New York City" set_var EASYRSA_REQ_ORG "DigitalOcean" set_var EASYRSA_REQ_EMAIL "admin@example.com" set_var EASYRSA_REQ_OU "Community"

      When you are finished, save and close the file. If you are using nano, you can do so by pressing CTRL+X, then Y and ENTER to confirm. You are now ready to build your CA.

      To create the root public and private key pair for your Certificate Authority, run the ./easy-rsa command again, this time with the build-ca option:

      In the output, you’ll see some lines about the OpenSSL version and you will be prompted to enter a passphrase for your key pair. Be sure to choose a strong passphrase, and note it down somewhere safe. You will need to input the passphrase any time that you need to interact with your CA, for example to sign or revoke a certificate.

      You will also be asked to confirm the Common Name (CN) for your CA. The CN is the name used to refer to this machine in the context of the Certificate Authority. You can enter any string of characters for the CA’s Common Name but for simplicity’s sake, press ENTER to accept the default name.

      Output

      . . . Enter New CA Key Passphrase: Re-Enter New CA Key Passphrase: . . . Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/sammy/easy-rsa/pki/ca.crt

      Note: If you don’t want to be prompted for a password every time you interact with your CA, you can run the build-ca command with the nopass option, like this:

      • ./easyrsa build-ca nopass

      You now have two important files — ~/easy-rsa/pki/ca.crt and ~/easy-rsa/pki/private/ca.key — which make up the public and private components of a Certificate Authority.

      • ca.crt is the CA’s public certificate file. Users, servers, and clients will use this certificate to verify that they are part of the same web of trust. Every user and server that uses your CA will need to have a copy of this file. All parties will rely on the public certificate to ensure that someone is not impersonating a system and performing a Man-in-the-middle attack.

      • ca.key is the private key that the CA uses to sign certificates for servers and clients. If an attacker gains access to your CA and, in turn, your ca.key file, you will need to destroy your CA. This is why your ca.key file should only be on your CA machine and that, ideally, your CA machine should be kept offline when not signing certificate requests as an extra security measure.

      With that, your CA is in place and it is ready to be used to sign certificate requests, and to revoke certificates.

      Step 4 — Distributing your Certificate Authority’s Public Certificate

      Now your CA is configured and ready to act as a root of trust for any systems that you want to configure to use it. You can add the CA’s certificate to your OpenVPN servers, web servers, mail servers, and so on. Any user or server that needs to verify the identity of another user or server in your network should have a copy of the ca.crt file imported into their operating system’s certificate store.

      To import the CA’s public certificate into a second Linux system like another server or a local computer, first obtain a copy of the ca.crt file from your CA server. You can use the cat command to output it in a terminal, and then copy and paste it into a file on the second computer that is importing the certificate. You can also use tools like scp, rsync to transfer the file between systems. However we’ll use copy and paste with nano in this step since it will work on all systems.

      As your non-root user on the CA Server, run the following command:

      • cat ~/easy-rsa/pki/ca.crt

      There will be output in your terminal that is similar to the following:

      Output

      -----BEGIN CERTIFICATE----- MIIDSzCCAjOgAwIBAgIUcR9Crsv3FBEujrPZnZnU4nSb5TMwDQYJKoZIhvcNAQEL BQAwFjEUMBIGA1UEAwwLRWFzeS1SU0EgQ0EwHhcNMjAwMzE4MDMxNjI2WhcNMzAw . . . . . . -----END CERTIFICATE-----

      Copy everything, including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines and the dashes.

      On your second Linux system use nano or your preferred text editor to open a file called /tmp/ca.crt:

      Paste the contents that you just copied from the CA Server into the editor. When you are finished, save and close the file. If you are using nano, you can do so by pressing CTRL+X, then Y and ENTER to confirm.

      Now that you have a copy of the ca.crt file on your second Linux system, it is time to import the certificate into its operating system certificate store.

      On Debian and Ubuntu based systems, run the following commands to import the certificate:

      Debian and Ubuntu derived distributions

      • cp /tmp/ca.crt /usr/local/share/ca-certificates/
      • update-ca-certificates

      To import the CA Server’s certificate on CentOS, Fedora, or RedHat based system, copy and paste the file contents onto the system just like in the previous example in a file called /tmp/ca.crt. Next, you’ll copy the certificate into /etc/pki/ca-trust/source/anchors/, then run the update-ca-trust command.

      CentOS, Fedora, RedHat distributions

      • sudo cp /tmp/ca.crt /etc/pki/ca-trust/source/anchors/
      • update-ca-trust

      Now your second Linux system will trust any certificate that has been signed by the CA server.

      Note: If you are using your CA with web servers and use Firefox as a browser you will need to import the public ca.crt certificate into Firefox directly. Firefox does not use the local operating system’s certificate store. For details on how to add your CA’s certificate to Firefox please see this support article from Mozilla on Setting Up Certificate Authorities (CAs) in Firefox.

      If you are using your CA to integrate with a Windows environment or desktop computers, please see the documentation on how to use certutil.exe to install a CA certificate.

      If you are using this tutorial as a prerequisite for another tutorial, or are familiar with how to sign and revoke certificates you can stop here. If you would like to learn more about how to sign and revoke certificates, then the following optional section will explain each process in detail.

      (Optional) — Creating Certificate Signing Requests and Revoking Certificates

      The following sections of the tutorial are optional. If you have completed all the previous steps then you have a fully configured and working Certificate Authority that you can use as a prerequisite for other tutorials. You can import your CA’s ca.crt file and verify certificates in your network that have been signed by your CA.

      If you would like to practice and learn more about how to sign certificate requests, and how to revoke certificates, then these optional sections will explain how both processes work.

      (Optional) — Creating and Signing a Practice Certificate Request

      Now that you have a CA ready to use, you can practice generating a private key and certificate request to get familiar with the signing and distribution process.

      A Certificate Signing Request (CSR) consists of three parts: a public key, identifying information about the requesting system, and a signature of the request itself, which is created using the requesting party’s private key. The private key will be kept secret, and will be used to encrypt information that anyone with the signed public certificate can then decrypt.

      The following steps will be run on your second Linux system Debian, Ubuntu, or distribution that is derived from either of those. It can be another remote server, or a local Linux machine like a laptop or a desktop computer. Since easy-rsa is not available by default on all systems, we’ll use the openssl tool to create a practice private key and certificate.

      openssl is usually installed by default on most Linux distributions, but just to be certain, run the following on your system:

      • sudo apt update
      • sudo apt install openssl

      When you are prompted to install openssl enter y to continue with the installation steps. Now you are ready to create a practice CSR with openssl.

      The first step that you need to complete to create a CSR is generating a private key. To create a private key using openssl, create a practice-csr directory and then generate a key inside it. We will make this request for a fictional server called sammy-server, as opposed to creating a certificate that is used to identify a user or another CA.

      • mkdir ~/practice-csr
      • cd ~/practice-csr
      • openssl genrsa -out sammy-server.key

      Output

      Generating RSA private key, 2048 bit long modulus (2 primes) . . . . . . e is 65537 (0x010001)

      Now that you have a private key you can create a corresponding CSR, again using the openssl utility. You will be prompted to fill out a number of fields like Country, State, and City. You can enter a . if you’d like to leave a field blank, but be aware that if this were a real CSR, it is best to use the correct values for your location and organization:

      • openssl req -new -key sammy-server.key -out sammy-server.req

      Output

      . . . ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:New York Locality Name (eg, city) [Default City]:New York City Organization Name (eg, company) [Default Company Ltd]:DigitalOcean Organizational Unit Name (eg, section) []:Community Common Name (eg, your name or your server's hostname) []:sammy-server Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

      If you would like to automatically add those values as part of the openssl invocation instead of via the interactive prompt, you can pass the -subj argument to OpenSSL. Be sure to edit the highlighted values to match your practice location, organization, and server name:

      • openssl req -new -key sammy-server.key -out server.req -subj
      • /C=US/ST=New York/L=New York City/O=DigitalOcean/OU=Community/CN=sammy-server

      To verify the contents of a CSR, you can read in a request file with openssl and examine the fields inside:

      • openssl req -in sammy-server.req -noout -subject

      Output

      subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server

      Once you’re happy with the subject of your practice certificate request, copy the sammy-server.req file to your CA server using scp:

      • scp sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req

      In this step you generated a Certificate Signing Request for a fictional server called sammy-server. In a real-world scenario, the request could be from something like a staging or development web server that needs a TLS certificate for testing; or it could come from an OpenVPN server that is requesting a certificate so that users can connect to a VPN. In the next step, we’ll proceed to signing the certificate signing request using the CA Server’s private key.

      (Optional) — Signing a CSR

      In the previous step, you created a practice certificate request and key for a fictional server. You copied it to the /tmp directory on your CA server, emulating the process that you would use if you had real clients or servers sending you CSR requests that need to be signed.

      Continuing with the fictional scenario, now the CA Server needs to import the practice certificate and sign it. Once a certificate request is validated by the CA and relayed back to a server, clients that trust the Certificate Authority will also be able to trust the newly issued certificate.

      Since we will be operating inside the CA’s PKI where the easy-rsa utility is available, the signing steps will use the easy-rsa utility to make things easier, as opposed to using the openssl directly like we did in the previous example.

      The first step to sign the fictional CSR is to import the certificate request using the easy-rsa script:

      • cd ~/easy-rsa
      • ./easyrsa import-req /tmp/sammy-server.req sammy-server

      Output

      . . . The request has been successfully imported with a short name of: sammy-server You may now use this name to perform signing operations on this request.

      Now you can sign the request by running the easyrsa script with the sign-req option, followed by the request type and the Common Name that is included in the CSR. The request type can either be one of client, server, or ca. Since we’re practicing with a certificate for a fictional server, be sure to use the server request type:

      • ./easyrsa sign-req server sammy-server

      In the output, you’ll be asked to verify that the request comes from a trusted source. Type yes then press ENTER to confirm this:

      Output

      You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 3650 days: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes . . . Certificate created at: /home/sammy/easy-rsa/pki/issued/sammy-server.crt

      If you encrypted your CA key, you’ll be prompted for your password at this point.

      With those steps complete, you have signed the sammy-server.req CSR using the CA Server’s private key in /home/sammy/easy-rsa/pki/private/ca.key. The resulting sammy-server.crt file contains the practice server’s public encryption key, as well as a new signature from the CA Server. The point of the signature is to tell anyone who trusts the CA that they can also trust the sammy-server certificate.

      If this request was for a real server like a web server or VPN server, the last step on the CA Server would be to distribute the new sammy-server.crt and ca.crt files from the CA Server to the remote server that made the CSR request:

      • scp pki/issued/sammy-server.crt sammy@your_server_ip:/tmp
      • scp pki/ca.crt sammy@your_server_ip:/tmp

      At this point, you would be able to use the issued certificate with something like a web server, a VPN, configuration management tool, database system, or for client authentication purposes.

      (Optional) — Revoking a Certificate

      Occasionally, you may need to revoke a certificate to prevent a user or server from using it. Perhaps someone’s laptop was stolen, a web server was compromised, or an employee or contractor has left your organization.

      To revoke a certificate, the general process follows these steps:

      1. Revoke the certificate with the ./easyrsa revoke client_name command.
      2. Generate a new CRL with the ./easyrsa gen-crl command.
      3. Transfer the updated crl.pem file to the server or servers that rely on your CA, and on those systems copy it to the required directory or directories for programs that refer to it.
      4. Restart any services that use your CA and the CRL file.

      You can use this process to revoke any certificates that you’ve previously issued at any time. We’ll go over each step in detail in the following sections, starting with the revoke command.

      Revoking a Certificate

      To revoke a certificate, navigate to the easy-rsa directory on your CA server:

      Next, run the easyrsa script with the revoke option, followed by the client name you wish to revoke. Following the practice example above, the Common Name of the certificate is sammy-server:

      • ./easyrsa revoke sammy-server

      This will ask you to confirm the revocation by entering yes:

      Output

      Please confirm you wish to revoke the certificate with the following subject: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Continue with revocation: yes . . . Revoking Certificate 8348B3F146A765581946040D5C4D590A . . .

      Note the highlighted value on the Revoking Certificate line. This value is the unique serial number of the certificate that is being revoked. If you want to examine the revocation list in the last step of this section to verify that the certificate is in it, you’ll need this value.

      After confirming the action, the CA will revoke the certificate. However, remote systems that rely on the CA have no way to check whether any certificates have been revoked. Users and servers will still be able to use the certificate until the CA’s Certificate Revocation List (CRL) is distributed to all systems that rely on the CA.

      In the next step you’ll generate a CRL or update an existing crl.pem file.

      Generating a Certificate Revocation List

      Now that you have revoked a certificate, it is important to update the list of revoked certificates on your CA server. Once you have an updated revocation list you will be able to tell which users and systems have valid certificates in your CA.

      To generate a CRL, run the easy-rsa command with the gen-crl option while still inside the ~/easy-rsa directory:

      If you have used a passphrase when creating your ca.key file, you will be prompted to enter it. The gen-crl command will generate a file called crl.pem, containing the updated list of revoked certificates for that CA.

      Next you’ll need to transfer the updated crl.pem file to all servers and clients that rely on this CA each time you run the gen-crl command. Otherwise, clients and systems will still be able to access services and systems that use your CA, since those services need to know about the revoked status of the certificate.

      Transferring a Certificate Revocation List

      Now that you have generated a CRL on your CA server, you need to transfer it to remote systems that rely on your CA. To transfer this file to your servers, you can use the scp command.

      Note: This tutorial explains how to generate and distribute a CRL manually. While there are more robust and automated methods to distribute and check revocation lists like OCSP-Stapling, configuring those methods is beyond the scope of this article.

      Ensure you are logged into your CA server as your non-root user and run the following, substituting in your own server IP or DNS name in place of your_server_ip:

      • scp ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp

      Now that the file is on the remote system, the last step is to update any services with the new copy of the revocation list.

      Updating Services that Support a CRL

      Listing the steps that you need to use to update services that use the crl.pem file is beyond the scope of this tutorial. In general you will need to copy the crl.pem file into the location that the service expects and then restart it using systemctl.

      Once you have updated your services with the new crl.pem file, your services will be able to reject connections from clients or servers that are using a revoked certificate.

      Examining and Verifying the Contents of a CRL

      If you would like to examine a CRL file, for example to confirm a list of revoked certificates, use the following openssl command from within your easy-rsa directory on your CA server:

      • cd ~/easy-rsa
      • openssl crl -in pki/crl.pem -noout -text

      You can also run this command on any server or system that has the openssl tool installed with a copy of the crl.pem file. For example, if you transferred the crl.pem file to your second system and want to verify that the sammy-server certificate is revoked, you can use an openssl command like the following, substituting the serial number that you noted earlier when you revoked the certificate in place of the highlighted one here:

      • openssl crl -in /tmp/crl.pem -noout -text |grep -A 1 8348B3F146A765581946040D5C4D590A

      Output

      Serial Number: 8348B3F146A765581946040D5C4D590A Revocation Date: Apr 1 20:48:02 2020 GMT

      Notice how the grep command is used to check for the unique serial number that you noted in the revocation step. Now you can verify the contents of your Certificate Revocation List on any system that relies on it to restrict access to users and services.

      Conclusion

      In this tutorial you created a private Certificate Authority using the Easy-RSA package on a standalone Debian 10 server. You learned how the trust model works between parties that rely on the CA. You also created and signed a Certificate Signing Request (CSR) for a practice server and then learned how to revoke a certificate. Finally, you learned how to generate and distribute a Certificate Revocation List (CRL) for any system that relies on your CA to ensure that users or servers that should not access services are prevented from doing so.

      Now you can issue certificates for users and use them with services like OpenVPN. You can also use your CA to configure development and staging web servers with certificates to secure your non-production environments. Using a CA with TLS certificates during development can help ensure that your code and environments match your production environment as closely as possible.

      If you would like to learn more about how to use OpenSSL, our OpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRs tutorial has lots of additional information to help you become more familiar with OpenSSL fundamentals.



      Source link