1 IntroductionAfter installing the
It is assumed that the vast majority of This document is prepared under Contract Number HSHQDC-14-C-B0035 for DHS S&T CSD 1.1 How to Proceed?
Three questions will give broad answers to what must be done next to
configure your
The remaining sections in this Guide provide further details and instructions for configuring the software for the different types of RPKI systems.
|
Table of Contents
|
2 Setting Up a Relying Party System
There are two central Relying-Party tools:
rcynic is the primary validation program and checks syntax, signatures, expiration times, and conformance to the profiles for RPKI objects. The other Relying-Party tools use the output fromrcynic .rpki-rtr provides the rpki-rtr protocol.
A third tool,
Configuration of these objects and the software tools is described in this section.
2.1 Files and Directories
The
2.1.1 rcynic.conf Configuration File
The
It is imperative that this file be set up properly in order for the
A default version of this file is created when the
The following fields must be checked for validity in the local environment:
authenticated - directory forrcynic -validated objects. Ensure that this directory exists and may be written byrcynic 's user.lockfile -rcynic 's lock file.log-level - logging level.rsync-program - path to thersync program.trust-anchor - path to one RPKI Trust Anchor file.trust-anchor-directory - the directory that will hold RPKI Trust Anchor and Trust Anchor Locator files.trust-anchor-locator - path to one RPKI Trust Anchor Locator file.unauthenticated - directory wherercynic will store unauthenticated data.
Values do not need to be given to each of
More information about these configuration fields and the
2.1.2 Trust Anchors and Trust Anchor Locators
Trust Anchors (TAs) are represented as DER-formatted self-signed X.509 certificates.
A Trust Anchor Locator (TALs) is a file in the format specified in
RFC-6490
, consisting of the
Either TAs or TALs (or a mix of both) can be used by the Relying-Party
software. The
| Configuration Field | Description |
|---|---|
| This field specifies a Trust Anchor by naming the local file containing
the TA.
| |
| This field specifies a Trust Anchor Locator by naming a local file
containing the file containing the TAL.
| |
| This field specifies a directory containing Trust Anchors and or Trust
Anchor Locators. Files in the given will be processed as TAs if their names
have the "
|
Example of a minimal
[rcynic]
trust-anchor-locator.0 = trust-anchors/apnic.tal
trust-anchor-locator.1 = trust-anchors/ripe.tal
trust-anchor-locator.2 = trust-anchors/afrinic.tal
trust-anchor-locator.3 = trust-anchors/lacnic.tal
Eventually, this should all be collapsed into a single Trust Anchor,
at which point the above configuration could become something like:
[rcynic]
trust-anchor-locator = trust-anchors/iana.tal
In practice, TALs are more common than TAs, as they reduce the amount
of locally configured data. TALs also allow the TA itself to be updated
without requiring reconfiguration of validators like
Trust Anchors do not need to be self-signed, but many programs
(including OpenSSL) assume that they will be. The
2.1.3 Selecting Trust Anchors
Validation in the RPKI system requires a set of Trust Anchors to use as a starting point when checking certificate chains. By definition, Trust Anchors can only be selected by the Relying Party.
A default set of Trust Anchors is supplied with the
As of this writing, there is no single global Trust Anchor for the RPKI
system, so you have to provide separate Trust Anchors for each Regional
Internet Registry (RIR) which is publishing RPKI data. The
ARIN's trust anchor locator is absent from the default set of Trust Anchors. This is the direct result of a deliberate policy decision by ARIN to require anyone using their Trust Anchor to jump through legal hoops. If ARIN changes this policy, their Trust Anchor Locator with be included along with those of the other RIRs.
Remember: It's only a Trust Anchor if you trust it. That decision can only be made by you.
2.2 rcynic Configuration
There are two methods of running
- run from
cron viarcynic-cron (default method) - run
rcynic in achroot() jail environment
These methods are described below.
2.2.1 Running rcynic from cron()
The default configuration created by used in
An installation may have additional requirements that aren't handled by
See the instructions for setting up
hierarchical
2.2.2 Running rcynic in a chroot() Environment
This section describes the process of setting up
To enable
2.2.2.1 Creating the chroot Jail Environment
By far the most complicated part of setting up Set-up requirements:
- You'll either need statically linked copies of
rcynic andrsync , or you'll need to figure out which shared libraries these programs need (try using theldd command). Here we assume statically linked binaries, because that's simpler, but be warned that statically linked binaries are not even possible on some platforms, whether due to conscious decisions on the part of operating system vendors or due to hidden use of dynamic loading by other libraries at runtime. Once again, theMakefiles attempt to do the correct thing for your environment if they know what it is, but they might get it wrong. - You may find that the dynamic loader looks in a different place than
you (and the
Makefiles ) would expect when running within thechroot jail. For example, you might think that library/usr/local/lib/libfoo.so being installed into a jail named/var/rcynic should go into/var/rcynic/usr/local/lib/libfoo.so , but we've seen cases where the dynamic loader ended up expecting to find it in/var/rcynic/lib/libfoo.so . Getting this right may require some trial and error testing. - You'll need a
chroot wrapper program. As mentioned above,rcynic-cron can act as that wrapper program. This is recommended because it works the same way on all platforms and doesn't require additional external programs. Otherwise, you'll have to find a suitable wrapper program. Your platform may already have one (.e.g., FreeBSD has/usr/sbin/chroot ). If it doesn't, you can download Wietse Venema'schrootuid program from ftp://ftp.porcupine.org/pub/security/chrootuid1.3.tar.gz.
Warning: The
Absolute pathnames are used throughout these set-up instructions. This is not
an accident. Programs running in jails under
Unfortunately, the precise details of setting up a proper
- Build the static binaries.
You might want to test them at this stage too, although you can defer that until after you've got the jail built. - Create a userid under which to run
rcynic .
Here we'll assume that's a user named rcynic, whose default group is also named rcynic. Do not add any other userids to the rcynic group unless you really know what you are doing. - Build the jail environment.
You'll need, at minimum, a directory in which to put the binaries, a subdirectory tree that's writable by the userid which will be runningrcynic andrsync , your trust anchors, and whatever device inodes the various libraries need on your system. Most likely the devices that matter will be/dev/null ,/dev/random , and/dev/urandom ; if you're running a FreeBSD system withdevfs , you do this by mounting and configuring adevfs instance in the jail, on other platforms you probably use themknod program or something similar.Important: Other than the directories that you want
rcynic andrsync to be able to modify, nothing in the initial jail setup should be writable by the rcynic userid. In particular,rcynic andrsync should not be allowed to modify: their own binary images, any of the configuration files, or your trust anchors. It's simplest just to have root own all the files and directories thatrcynic andrsync are not allowed to modify, and make sure that the permissions for all of those directories and files make them writable only by root.The following instructions will create a sample jail environment. It is assumed that
/var/rcynic will hold the jail.- Create the jail hierarchy.
The following commands create a sample jail tree.$ mkdir /var/rcynic $ mkdir /var/rcynic/bin $ mkdir /var/rcynic/data $ mkdir /var/rcynic/dev $ mkdir /var/rcynic/etc $ mkdir /var/rcynic/etc/trust-anchors - Copy Trust Anchors into jail.
Trust anchors must be copied into/var/rcynic/etc/trust-anchors . - Copy
rcynic andrsync into jail.
Copy the statically linkedrcynic andrsync into/var/rcynic/bin . - Copy system files into jail.
Copy/etc/resolv.conf and/etc/localtime (if it exists) into/var/rcynic/etc . - Create
rcynic.conf .
Create anrcynic configuration file as/var/rcynic/etc/rcynic.conf . Path names in this file must match the jail setup; more on this below. - Set required jail ownerships.
The following commands will set owner, group, and file permissions for several directories.$ chmod -R go-w /var/rcynic $ chown -R root:wheel /var/rcynic $ chown -R rcynic:rcynic /var/rcynic/data devfs mounts.
If you're usingdevfs , arrange for it to be mounted at/var/rcynic/dev ; otherwise, create whatever device inodes you need in/var/rcynic/dev and make sure that they have sane permissions. It is probably safe to assume that whatever permissions are used in your system/dev directory may be considered sane.- Configure
rcynic.conf . Editrcynic.conf to match this configuration:[rcynic] rsync-program = /bin/rsync authenticated = /data/authenticated unauthenticated = /data/unauthenticated xml-summary = /data/rcynic.xml trust-anchor-directory = /etc/trust-anchors
- Create the jail hierarchy.
- Testing the Jail.
Once this is all set up,rcynic may be tested in the jail. Test it from the command line first. If that works, it should be able to be run undercron .chroot , chrootuid, and other programs of this type are usually intended to be run by root, and should not be setuid programs unless you really know what you are doing.Sample test command line:
# /usr/local/bin/chrootuid /var/rcynic rcynic /bin/rcynic -s -c /etc/rcynic.conf
2.2.2.2 Building Static Binaries
On FreeBSD, building a statically linked
For simplicity, we've taken the same approach with
$ make LDFLAGS='-static'
This isn't necessary on platforms where we know that static linking
works -- the default is static linking where supported.
2.2.2.3 syslog from chroot ed Environments
Depending on how the
altlog_proglist="named rcynic"
rcynic_chrootdir="/var/rcynic"
rcynic_enable="YES"
This tells
(Depending on the system, the actual daemon name may be something like
2.3 rpki-rtr Configuration
2.3.1 Post-processing of rcynic Output
If you are using
If a non-standard
/usr/local/bin/rpki-rtr cronjob /var/rcynic/data/authenticated /var/rcynic/rpki-rtr
The
As part of the configuration process, execute the
2.3.2 rpki-rtr 's Listener
A server listener must be set up that invokes
The details of how to set up a listener vary depending on the network protocol
and the operating system on which it is run. Below are three examples,
running under
2.3.2.1 rpki-rtr 's Listener with inetd
Running under
To run under
- Add an entry to
/etc/services defining a symbolic name for the port, if one doesn't exist already. At present, there is no well-known port defined for this protocol. This example will use port 42420 and the symbolic namerpki-rtr .Add this entry to
/etc/services :rpki-rtr 42420/tcp - Add the service line to /etc/inetd.conf:
rpki-rtr stream tcp nowait nobody /usr/local/bin/rpki-rtr rpki-rtr server /var/rcynic/rpki-rtr
This assumes that you want the server to run as user nobody, which is generally a safe choice. A new non-privileged user could be created for this purpose. DO NOT run the server as root; it shouldn't do anything bad, but it is a network server that doesn't need root access, therefore it shouldn't have root access.
2.3.2.2 rpki-rtr 's Listener with sshd
To run
- Decide whether to run a new instance of
sshd on a separate port or use the standard port.rpki-rtr doesn't care, but some people seem to think that it's somehow more secure to run this service on a different port. Setting upsshd in general is beyond the scope of this documentation, but most likely you can copy the bulk of your configuration from the standard configuration. - Configure
sshd to know about therpki-rtr subsystem. Add something like this to yoursshd.conf :Subsystem rpki-rtr /usr/local/bin/rpki-rtr - Configure the userid(s) you expect SSH clients to use to connect to the
server. For operational use you almost certainly do NOT want this user to
have a normal shell, instead you should configure its shell to be the server
(e.g.,
/usr/local/bin/rpki-rtr ) and its home directory to be therpki-rtr data directory (e.g.,/var/rcynic/rpki-rtr .) If you're using passwords to authenticate instead of SSH keys, which is not recommended, you will always need to set the password(s) here when configuring the userid(s). - Configure the
.ssh/authorized_keys file for your clients; if you're using the example values given above, this would be/var/rcynic/rpki-rtr/.ssh/authorized_keys . You can have multiple SSH clients using different keys all logging in as the same SSH user, you just have to list all of the SSH keys here. You may want to consider using acommand=parameter in the key line (see thesshd(8) man page) to lock down the SSH keys listed here so that they can only be used to run therpki-rtr service.
If you're running a separate
AuthorizedKeysFile /var/rcynic/rpki-rtr/.ssh/authorized_keys
There's a sample
2.3.2.3 rpki-rtr 's Listener with Generic Support
All of the caveats regarding plain TCP apply to
/usr/local/bin/rpki-rtr listener 42420 /var/rcynic/rpki-rtr
2.3.2.4 rpki-rtr 's Listener with Other Programs
You can also run this code under other such network service programs. These
include such programs as
You should, however, care whether the channel you have chosen is secure; it
doesn't make a lot of sense to go to all the trouble of checking RPKI data
then let the bad guys feed bad data into your routers anyway because you were
running the
2.4 Setting Up a Local cron Wrapper
The tools to be run by a
The exact sequence for invoking
If you're not using
Once you've written this wrapper, add an entry in your
An appropriate set of repository directory must be created for use by the Relying-Party tools. These commands will create the directory and set its ownership appropriately.
# mkdir /var/rcynic/rpki-rtr
# chown rcynic /var/rcynic/rpki-rtr
On FreeBSD or Mac OSX, this wrapper script might look like this:
#!/bin/sh -
/usr/sbin/chroot -u rcynic -g rcynic /var/rcynic /bin/rcynic -c /etc/rcynic.conf || exit
/var/rcynic/bin/rcynic-html /var/rcynic/data/rcynic.xml /usr/local/www/data/rcynic
/usr/bin/su -m rcynic -c '/usr/local/bin/rpki-rtr cronjob /var/rcynic/data/authenticated /var/rcynic/rpki-rtr'
On GNU/Linux systems, the script might look like this if you use the
#!/bin/sh -
/usr/bin/chrootuid /var/rcynic rcynic /bin/rcynic -c /etc/rcynic.conf || exit
/var/rcynic/bin/rcynic-html /var/rcynic/data/rcynic.xml /var/www/rcynic
/usr/bin/su -m rcynic -c '/usr/local/bin/rpki-rtr cronjob /var/rcynic/data/authenticated /var/rcynic/rpki-rtr'
If you use the
/usr/sbin/chroot --userspec rcynic:rcynic /var/rcynic /bin/rcynic -c /etc/rcynic.conf || exit
2.5 Running a Hierarchical rsync Configuration
Having every relying party on the Internet contact every publication service
is not terribly efficient. In many cases, it may make more sense to use a
hierarchical configuration in which a few "gatherer" Relying Parties contact
the publication servers directly, while a collection of other Relying Parties
get their raw data from the gatherers.
Note: The Relying Parties in this configuration still perform their own validation, they just let the gatherers do the work of collecting the unvalidated data for them.
A gatherer in a configuration like this would look just like a stand-alone
Relying Party as discussed above. The only real difference is that a gatherer
must also make its unauthenticated data collection available to other Relying
Parties. Assuming the standard configuration, this will be the directory
There are two slightly different ways to do this with
- Via unauthenticated
rsync , by configuring anrsyncd.conf "module".
- Via
rsync over a secure transport protocol such asssh .
Since the downstream Relying Party performs its own validation in any case,
either of these will work, but using a secure transport such as
The script for a downstream Relying Party using
#!/bin/sh -
PATH=/usr/bin:/bin:/usr/local/bin
umask 022
eval `/usr/bin/ssh-agent -s` >/dev/null
/usr/bin/ssh-add /root/rpki_ssh_id_rsa 2>&1 | /bin/fgrep -v 'Identity added:'
hosts='larry.example.org moe.example.org curly.example.org'
for host in $hosts
do
/usr/bin/rsync --archive --update --safe-links rpkisync@${host}:/var/rcynic/data/unauthenticated/ /var/rcynic/data/unauthenticated.${host}/
done
eval `/usr/bin/ssh-agent -s -k` >/dev/null
for host in $hosts
do
/usr/sbin/chroot -u rcynic -g rcynic /var/rcynic /bin/rcynic -c /etc/rcynic.conf -u /data/unauthenticated.${host}
/var/rcynic/bin/rcynic-html /var/rcynic/data/rcynic.xml /usr/local/www/data/rcynic.${host}
done
cd /var/rcynic/rpki-rtr
/usr/bin/su -m rcynic -c '/usr/local/bin/rpki-rtr cronjob /var/rcynic/data/authenticated'
where
If you want to lock this down a little tighter, you could use
To avoid allowing the downstream Relying Parties any sort of login access at
all on the gatherer machines,
#!/bin/sh -
PATH=/usr/bin:/bin:/usr/local/bin
umask 022
hosts='larry.example.org moe.example.org curly.example.org'
for host in $hosts
do
/usr/bin/rsync --archive --update --safe-links rsync://${host}/unauthenticated/ /var/rcynic/data/unauthenticated.${host}/
done
for host in $hosts
do
/usr/sbin/chroot -u rcynic -g rcynic /var/rcynic /bin/rcynic -c /etc/rcynic.conf -u /data/unauthenticated.${host}
/var/rcynic/bin/rcynic-html /var/rcynic/data/rcynic.xml /usr/local/www/data/rcynic.${host}
done
cd /var/rcynic/rpki-rtr
/usr/bin/su -m rcynic -c '/usr/local/bin/rpki-rtr cronjob /var/rcynic/data/authenticated'
Where "unauthenticated" here is an
[unauthenticated]
read only = yes
transfer logging = yes
path = /var/rcynic/data/unauthenticated
comment = Unauthenticated RPKI data
3 Setting Up a Configuration Authority System
It is assumed that the vast majority of
The sections that follow have the beginnings of a discussion on setting up a Configuration Authority system. These are incomplete and will be completed soon.
3.1 Files and Directories
The
3.1.1 rpki.conf Configuration File
The
The
[myrpki]
irdbd_server_host = localhost
irdbd_server_port = 4403
[irdbd]
server-port = ${myrpki::irdbd_server_port}
The
The first subsection below describes the daemon-execution flags that must be set in order to start only those daemons that should be run by your installation. The following subsections describe particular fields in each configuration section that must be checked.
After checking the
Details on the
3.1.1.1 Execution Flags
There are several
There are two separate sets of
| Entry Name | Purpose | Default Value |
|---|---|---|
| Run the | yes | |
| Run the | yes | |
| Run the | no |
There is another set of entries that refer to these flag entries. In most cases, the values of these entries should not be changed. These entries are expected to correspond to the referenced entries.
The following table lists these referencing entries.
| Entry Name | Referenced Entry | Controlled Daemon |
|---|---|---|
| ${myrpki::run_rpkid} | ||
| ${myrpki::run_rpkid} | ||
| ${myrpki::run_pubd} | ||
| ${myrpki::run_rootd} |
The only case where the
3.1.1.2 [autoconf] Entries
The
| Entry Name | Default Value |
|---|---|
3.1.1.3 [myrpki] Entries
The
There are three directory entries that must be checked for validity. These
are referenced in other sections, and
| Entry Name | Default Value | ||||
|---|---|---|---|---|---|
There are a set of server entries that must be checked. There is a host and
a port entry for each of the
| Entry Name | Default Value | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| hostname (FQDN)
| 4404
| "localhost"
| 4403
| hostname (FQDN)
| 4402
| "localhost"
| 4401
| |
The
| Entry Name | Default Value | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| "rpki"
| auto-generated at install time
| "rpkid"
| "irdbd"
| "pubd"
| |
3.1.1.4 [rpkid] Entries
The
There are five entries for
These file values should not be changed unless you really know what you're doing.
3.1.1.5 [irdbd] Entries
The
3.1.1.6 [pubd] Entries
The
There are four entries for
These values should not be changed unless you really know what you're doing.
3.1.1.7 [rootd] Entries
The
As is explained elsewhere, the
There are nine entries for
These values should not be changed unless you really know what you're doing.
3.1.1.8 [web_portal] Entries
The
The single non-reference entry is the
3.1.2 Root Certificates
If a root CA will be run using
The command sequence below demonstrates using
# cd /usr/share/rpki
# wget https://subvert-rpki.hactrn.net/trunk/potpourri/generate-root-certificate --no-check-certificate
# python generate-root-certificate
# mkdir /usr/share/rpki/publication.root
# rsync root.cer /usr/share/rpki/publication.root
# rm /etc/rpki/trust-anchors/*
# rsync root.tal /etc/rpki/trust-anchors/TestRoot.tal
This command sequence creates a root certificate, key, and Trust Anchor List. The certificate is saved in a publication directory. The TAL is moved to become the only set of Trust Anchors used by the RPKI software.
This command sequence assumes that the
| Entry Name | Assumed Value |
|---|---|
3.1.3 MySQL Database Configuration
MySQL is used to manage the
See the Configuration File Reference for details on the configuration file settings the daemons will use to find and authenticate themselves to their respective databases.
3.1.3.1 Automated Database Configuration
The
$ rpki-sql-setup
Please enter your MySQL root password:
The man page for
3.1.3.2 Manual Database Configuration
The
Two databases must be created:
$ mysql -u root -p
mysql> CREATE DATABASE irdb_database;
mysql> GRANT all ON irdb_database.* TO irdb_user@localhost IDENTIFIED BY 'irdb_password';
mysql> CREATE DATABASE rpki_database;
mysql> GRANT all ON rpki_database.* TO rpki_user@localhost IDENTIFIED BY 'rpki_password';
mysql> USE rpki_database;
mysql> SOURCE $top/schemas/sql/rpkid.sql;
mysql> COMMIT;
mysql> quit
If the
$ mysql -u root -p
mysql> CREATE DATABASE pubd_database;
mysql> GRANT all ON pubd_database.* TO pubd_user@localhost IDENTIFIED BY 'pubd_password';
mysql> USE pubd_database;
mysql> SOURCE $top/schemas/sql/pubd.sql;
mysql> COMMIT;
mysql> quit
3.1.4 rsyncd.conf Configuration File
The
The following is a sample
[rpki]
path = /usr/share/rpki/publication
use chroot = no
read only = yes
transfer logging = yes
comment = for rpki.net's pubd daemon
This configuration section must be adapted for your own installation. In
particular, the
The
$ rpkichk -list -untranslate | grep ^publication_base_directory
publication_base_directory "${autoconf::datarootdir}/rpki/publication"
$ rpkichk -list | grep ^publication_base_directory
publication_base_directory "/usr/share/rpki/publication"
The
Details on the
3.2 irdbd Configuration
In production use, this service is a function of the IRBE stub.
Configuration for
3.3 pubd Configuration
The
3.3.1 Running pubd on the Same Server
The
3.3.2 Running pubd on a Different Server
The following guidelines describe how to set up an
Most of the configuration is the same as in the normal case, but there are a few extra steps. The following instructions supplement the normal instructions, but do not replace them.
WARNING: These setup directions have not been tested extensively.
- On backend.example.org, create the
rpki.conf file as described in therpki.conf Configuration File section.
The following settings will be used:irbe_server_host = backend.example.org pubd_server_host = pubd.example.org - Customize
rpki.conf on backend.example.org:start_irdbd should be enabled.start_pubd should be disabled.
- Enable
run_pubd inrpki.conf . - Copy the
rpki.conf file to pubd.example.org. - Customize the
rpki.conf on pubd.example.org:start_irdbd should be disabled.start_pubd should be enabled.
- Ensure that the SQL databases have been set up on both servers.
The
rpki-sql-setup script should do the right thing in each case, based on the setting of thestart_ options. - Run
"rpkic initialize" on backend.example.org. This will create the BPKI and write out all of the necessary keys and certificates. These are the.cer ,.key , and.crl files. - The relevant BPKI files must be copied to pubd.example.org:
- the
.cer file, - the
.crl file, - the
pubd.key file.
- the
- Run
rpki-start-servers on the two server hosts when it's time to start the servers. - Do the usual setup, but keep in mind that the the back-end controlling
all of these servers runs on backend.example.org, so that is where
the
rpkic or GUI commands to manage the servers must be issued.rpkic and the GUI both know how to talk topubd over the network, so managing it remotely is fine.
3.4 rootd Configuration
Warnings against using the
rootd is a simple implementation intended for test use. It is not suitable for use in a production system.- You do not need to run
rootd unless one of the following conditions holds true:- You are IANA.
- You are certifying private address space.
- You are an RIR which refuses to accept IANA as the root of the public address hierarchy.
rootd . - The developers say that
rootd is a mess, and it needs to be rewritten and merged intorpkid . It doesn't use the publication protocol and it requires far too many configuration parameters.
3.5 rpkid Configuration
The
3.5.1 Running rpkid on the Same Server
The
3.5.2 Running rpkid on a Different Server
The following guidelines describe how to set up an
Most of the configuration is the same as in the normal case, but there are a few extra steps. The following instructions supplement the normal instructions, but do not replace them.
WARNING: These setup directions have not been tested extensively.
- On backend.example.org, create the
rpki.conf file as described in therpki.conf Configuration File section.
The following settings will be used:irbe_server_host = backend.example.org rpkid_server_host = rpkid.example.org - Customize
rpki.conf on backend.example.org:start_irdbd should be enabled.start_rpkid should be disabled.
- Enable
run_rpkid inrpki.conf . - Copy the
rpki.conf file to rpkid.example.org. - Customize
rpki.conf on rpkid.example.org:start_irdbd should be disabled.start_rpkid should be enabled.
- Ensure that the SQL databases have been set up on both servers.
The
rpki-sql-setup script should do the right thing in each case, based on the setting of thestart_ options. - Run
"rpkic initialize" on backend.example.org. This will create the BPKI and write out all of the necessary keys and certificates. These are the.cer ,.key , and.crl files. - The relevant BPKI files must be copied to rpkid.example.org:
- the
.cer file, - the
.crl file, - the
rpkid.key file.
- the
- Run
rpki-start-servers on the two server hosts when it's time to start the servers. - Do the usual setup, but keep in mind that the the back-end controlling
all of these servers runs on backend.example.org, so that is where
the
rpkic or GUI commands to manage the servers must be issued.rpkic and the GUI both know how to talk torpkid over the network, so managing it remotely is fine.
3.6 Initialization of Certification Authority Data
The Certification Authority data must be initialized. The
The command sequence below demonstrates the
# service rpki-ca restart
# cd /usr/share/rpki
# rpkic initialize
# rpkic configure_publication_client /usr/share/rpki/example-ca.example-ca.repository-request.xml
# rpkic configure_repository /usr/share/rpki/testCA.repository-response.xml
This example does not include the output from these commands.
The path used in the
The man page for
3.7 Web Interface Configuration
Once these other other things are set up, Users and Resource Holders must be defined for the Web Portal. See the Web Portal Administrator's Manual for details on how to create and modify the Web Portal's objects.
3.7.1 Configuring the Web Portal
The
See the Configuration File Reference for details.
3.7.2 Creating a Web Portal Superuser
A superuser for the Web Portal should be created. The
# rpki-manage
The man page for
3.7.3 Error Notifications via Email
By default, exceptions generated while the Web Portal is processing a request will be logged to the Apache log file. An email message will be sent to root@localhost as well.
If you wish to change where email is sent, you can edit
ADMINS = (('YOUR NAME', 'YOUR EMAIL ADDRESS'),)
For example,
ADMINS = (('Joe User', 'joe@example.com'),)
3.7.4 Cron Jobs for the Web Portal
The Web Portal makes use of some external data sources to display the
validation status of routing entries. Therefore, it is necessary to run
some background jobs periodically to refresh this data. The Web Portal
software makes use of the
3.7.4.1 Importing Routing Table Snapshots
In order for the Web Portal to display the validation status of routes covered by a resource holder's RPKI certificates, it needs a source of the currently announced global routing table. The Web Portal includes a script which can parse the output of the RouteViews full snapshot (warning: links to very large file!).
When the software is installed, there will be a
Create an entry in root's
30 */2 * * * /usr/local/sbin/rpkigui-import-routes
3.7.4.2 Importing ROAs
If you want the GUI's "routes" page to see ROAs when you click those buttons,
you will need to run
This data is imported by the
If you are running
3.7.4.3 Expiration Checking
The Web Portal can notify users when it detects that RPKI certificates will
expire in the near future. Run the
By default, it will warn of expiration 14 days in advance, but this may be
changed by using the
3.7.5 Verify the Web Portal is Working
To ensure that the Web Portal is working properly, navigate to https://YOURHOST/rpki/. You should see the login page for the Web Portal.
Enter the superuser name and password (as created in the section) in the login form. If the Web Portal is working properly, this will take you to the Web Portal's dashboard.
The Web Portal Administrator's Manual provides more information about administering the Web Portal.
3.7.6 Running the Web Portal as a Different User
By default, the Web Portal is run in embedded mode in
$ ./configure --enable-wsgi-daemon-mode[=user[:group]]
Where
When run in daemon mode, a Unix-domain socket will be created in the
same directory as the Apache log files. If the user you have specified to run
the Web Portal as does not have permission to read a file in that directory,
the web interface will return a "500 Internal Server Error" and you will see a
"Permission Denied Error" in your Apache logs. The solution to this is to use
the
WSGISocketPrefix /var/run/wsgi
This directive must not be placed inside of the <VirtualHost>
section. It must be located at the global scope.
See ModWSGI Configuration Directives for more information.
Sections of this document are derived or taken verbatim from Dragon Research Lab's RPKI Tools Manual.
Copyright (c) 2015, Parsons, Inc
All rights reserved