****** rcynic RPKI validator ****** rcynic is the core RPKI relying party tool, and is the code which performs the actual RPKI validation. Most of the other relying party tools just use rcynic's output. The name is short for "cynical rsync", because rcynic's task involves an interleaved process of rsync retrieval and validation. This code was developed on FreeBSD, and has been tested most heavily on FreeBSD versions 6-STABLE through 8-STABLE. It is also known to run work on Ubuntu (8.10) and Mac OS X (Snow Leopard). In theory it should run on any reasonably POSIX-like system. As far as we know rcynic does not use any seriously non- portable features, but neither have we done a POSIX reference manual lookup for every function call. Please report any portability problems. ***** Don't panic ***** rcynic has a lot of options, but it attempts to choose reasonable defaults where possible. The installation process will create a basic rcynic.conf file for you and set up the chroot jail. See the instructions for setting up a cron job for details on how to run rcynic automatically and feed its output into other relying party tools. ***** Overview ***** rcynic depends heavily on the OpenSSL libcrypto library, and requires a reasonably current version of OpenSSL with both RFC 3779 and CMS support. All certificates, CRLs, and CMS objects are in DER format, with filenames derived from the RPKI rsync URIs at which the data are published. All configuration is via an OpenSSL-style configuration file, except for selection of the name of the configuration file itself. A few of the parameters can also be set from the command line. The default name for the configuration is rcynic.conf; you can override this with the -c option on the command line. The config file uses OpenSSL's config file syntax, and you can set OpenSSL library configuration paramaters (eg, "engine" settings) in the config file as well. rcynic's own configuration parameters are in a section called "[rcynic]". Most configuration parameters are optional and have defaults which should do something reasonable if you are running rcynic in a test directory. If you're running rcynic as a system progran, perhaps under cron, you'll want to set additional parameters to tell rcynic where to find its data and where to write its output. The configuration file itself, however, is not optional. In order for rcynic to do anything useful, your configuration file MUST specify the file name(s) of one or more RPKI trust anchors or trust anchor locators. **** Trust anchors **** * To specify a trust anchor, use the trust-anchor directive to name the local file containing the trust anchor. * To specify a trust anchor locator (TAL), use the trust-anchor-locator directive to name a local file containing the trust anchor locator. Trust anchors are represented as DER-formatted X.509 self-signed certificate objects, but in practice trust anchor locators are more common, as they reduce the amount of locally configured data to the bare minimum and allow the trust anchor itself to be updated without requiring reconfiguration of validators like rcynic. A trust anchor locator is a file in the format specified in RFC- 6490, consisting of the rsync URI of the trust anchor followed by the Base64 encoding of the trust anchor's public key. Strictly speaking, trust anchors do not need to be self-signed, but many programs (including OpenSSL) assume that trust anchors will be self-signed. See the allow-non-self-signed-trust-anchor configuration option if you need to use a non-self-signed trust anchor, but be warned that the results, while technically correct, may not be useful. See the make-tal.sh script in this directory if you need to generate your own TAL file for a trust anchor. As of this writing, there still is no global trust anchor for the RPKI system, so you have to specify separate trust anchors for each Regional Internet Registry (RIR) which is publishing RPKI data: Example of a minimal config file specifying nothing but trust anchor locators: [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, so that relying parties don't need to sort this out on their own, at which point the above configuration could become something like: [rcynic] trust-anchor-locator = trust-anchors/iana.tal **** Output directories **** By default, rcynic uses two writable directory trees: unauthenticated:: Raw data fetched via rsync. In order to take full advantage of rsync's optimized transfers, you should preserve and reuse this directory across rcynic runs, so that rcynic need not re-fetch data that have not changed. authenticated:: Data which rcynic has checked. This is the real output of the process. authenticated is really a symbolic link to a directory with a name of the form authenticated., where is an ISO 8601 timestamp like 2001-04-01T01:23:45Z. rcynic creates a new timestamped directory every time it runs, and moves the symbolic link as an atomic operation when the validation process completes. The intent is that authenticated always points to the most recent usable validation results, so that programs which use rcynic's output don't need to worry about whether an rcynic run is in progress. rynic stores trust anchors specified via the trust-anchor-locator directive in the unauthenticated tree just like any other fetched object, and copies into the authenticated trees just like any other object once they pass rcynic's checks. rcynic copies trust anchors specified via the "trust-anchor" directive into the top level directory of the authenticated tree xxxxxxxx.n.cer, where xxxxxxxx and n are the OpenSSL object name hash and index within the resulting virtual hash bucket (the same as the c_hash Perl script that comes with OpenSSL would produce), and ".cer" is the literal string ".cer". The reason for this is that these trust anchors, by definition, are not fetched automatically, and thus do not really have publication URIs in the sense that every other object in these trees do. So rcynic uses a naming scheme which insures * that each trust anchor has a unique name within the output tree and * that trust anchors cannot be confused with certificates: trust anchors always go in the top level of the tree, data fetched via rsync always go in subdirectories. As currently implemented, rcynic does not attempt to maintain an in-memory cache of objects it might need again later. It does keep an internal cache of the URIs from which it has already fetched data in this pass, and it keeps a stack (actually, multiple stacks, to support parallel operations) containing the current certificate chain as it does its validation walk. All other data (eg, CRLs) are freed immediately after use and read from disk again as needed. From a database design standpoint, this is not very efficient, but as the rcynic's main bottlenecks are expected to be crypto and network operations, it seemed best to keep the design as simple as possible, at least until execution profiling demonstrates a real issue here. ***** Usage and configuration ***** **** Logging levels **** rcynic has its own system of logging levels, similar to what syslog() uses but customized to the specific task rcynic performs. log_sys_err Error from operating system or library log_usage_err Bad usage (local configuration error) log_data_err Bad data (broken certificates or CRLs) log_telemetry Normal chatter about rcynic's progress log_verbose Extra verbose chatter log_debug Only useful when debugging **** Command line options **** -c configfile Path to configuration file (default: rcynic.conf) -l loglevel Logging level (default: log_data_err) -s Log via syslog -e Log via stderr when also using syslog -j Start-up jitter interval (see below; default: 600) -V Print rcynic's version to standard output and exit -x Path to XML "summary" file (see below; no default) ***** Configuration file reference ***** rcynic uses the OpenSSL libcrypto configuration file mechanism. All libcrypto configuration options (eg, for engine support) are available. All rcynic- specific options are in the "[rcynic]" section. You MUST have a configuration file in order for rcynic to do anything useful, as the configuration file is the only way to list your trust anchors. Configuration variables: authenticated:: Path to output directory (where rcynic should place objects it has been able to validate). Default: rcynic-data/authenticated unauthenticated:: Path to directory where rcynic should store unauthenticatd data retrieved via rsync. Unless something goes horribly wrong, you want rcynic to preserve and reuse this directory across runs to minimize the network traffic necessary to bring your repository mirror up to date. Default: rcynic-data/unauthenticated rsync-timeout:: How long (in seconds) to let rsync run before terminating the rsync process, or zero for no timeout. You want this timeout to be fairly long, to avoid terminating rsync connections prematurely. It's present to let you defend against evil rsync server operators who try to tarpit your connection as a form of denial of service attack on rcynic. Default: 300 seconds. max-parallel-fetches:: Upper limit on the number of copies of rsync that rcynic is allowed to run at once. Used properly, this can speed up synchronization considerably when fetching from repositories built with sub-optimal tree layouts or when dealing with unreachable repositories. Used improperly, this option can generate excessive load on repositories, cause synchronization to be interrupted by firewalls, and generally creates create a public nuisance. Use with caution. As of this writing, values in the range 2-4 are reasonably safe. At least one RIR currently refuses service at settings above 4, and another RIR appears to be running some kind of firewall that silently blocks connections when it thinks decides that the connection rate is excessive. rcynic can't really detect all of the possible problems created by excessive values of this parameter, but if rcynic's report shows that both successful retrivial and skipped retrieval from the same repository host, that's a pretty good hint that something is wrong, and an excessive value here is a good first guess as to the cause. Default: 1 rsync-program:: Path to the rsync program. Default: rsync, but you should probably set this variable rather than just trusting the PATH environment variable to be set correctly. log-level:: Same as -l option on command line. Command line setting overrides config file setting. Default: log_log_err use-syslog:: Same as -s option on command line. Command line setting overrides config file setting. Values: true or false. Default: false use-stderr:: Same as -e option on command line. Command line setting overrides config file setting. Values: true or false. Default: false, but if neither use-syslog nor use-stderr is set, log output goes to stderr. syslog-facility:: Syslog facility to use. Default: local0 syslog-priority-xyz:: (where xyz is an rcynic logging level, above) Override the syslog priority value to use when logging messages at this rcynic level. Defaults: syslog-priority-log_sys_err err syslog-priority-log_usage_err err syslog-priority-log_data_err notice syslog-priority-log_telemetry info syslog-priority-log_verbose info syslog-priority-log_debug debug jitter:: Startup jitter interval, same as -j option on command line. Jitter interval, specified in number of seconds. rcynic will pick a random number within the interval from zero to this value, and will delay for that many seconds on startup. The purpose of this is to spread the load from large numbers of rcynic clients all running under cron with synchronized clocks, in particular to avoid hammering the RPKI rsync servers into the ground at midnight UTC. Default: 600 lockfile:: Name of lockfile, or empty for no lock. If you run rcynic under cron, you should use this parameter to set a lockfile so that successive instances of rcynic don't stomp on each other. Default: no lock xml-summary:: Enable output of a per-host summary at the end of an rcynic run in XML format. Some users prefer this to the log_telemetry style of logging, or just want it in addition to logging. Value: filename to which XML summary should be written; "-" will send XML summary to stdout. Default: no XML summary. allow-stale-crl:: Allow use of CRLs which are past their nextUpdate timestamp. This is usually harmless, but since there are attack scenarios in which this is the first warning of trouble, it's configurable. Values: true or false. Default: true prune:: Clean up old files corresponding to URIs that rcynic did not see at all during this run. rcynic invokes rsync with the --delete option to clean up old objects from collections that rcynic revisits, but if a URI changes so that rcynic never visits the old collection again, old files will remain in the local mirror indefinitely unless you enable this option. Note: Pruning only happens when run-rsync is true. When the run-rsync option is false, pruning is not done regardless of the setting of the prune option option. Values: true or false. Default: true allow-stale-manifest:: Allow use of manifests which are past their nextUpdate timestamp. This is probably harmless, but since it may be an early warning of problems, it's configurable. Values: true or false. Default: true require-crl-in-manifest:: Reject publication point if manifest doesn't list the CRL that covers the manifest EE certificate. Values: true or false. Default: false allow-object-not-in-manifest:: Allow use of otherwise valid objects which are not listed in the manifest. This is not supposed to happen, but is probably harmless. Values: true or false Default: true allow-digest-mismatch:: Allow use of otherwise valid objects which are listed in the manifest with a different digest value. You probably don't want to touch this. Values: true or false Default: true allow-crl-digest-mismatch:: Allow processing to continue on a publication point whose manifest lists a different digest value for the CRL than the digest of the CRL we have in hand. You probably don't want to touch this. Values: true or false Default: true allow-non-self-signed-trust-anchor:: Experimental. Attempts to work around OpenSSL's strong preference for self-signed trust anchors. Do not even consider enabling this unless you are intimately familiar with X.509 and really know what you are doing. Values: true or false. Default: false run-rsync:: Whether to run rsync to fetch data. You don't want to change this except when building complex topologies where rcynic running on one set of machines acts as aggregators for another set of validators. A large ISP might want to build such a topology so that they could have a local validation cache in each POP while minimizing load on the global repository system and maintaining some degree of internal consistancy between POPs. In such cases, one might want the rcynic instances in the POPs to validate data fetched from the aggregators via an external process, without the POP rcynic instances attempting to fetch anything themselves. Values: true or false. Default: true use-links:: Whether to use hard links rather than copying valid objects from the unauthenticated to authenticated tree. Using links is slightly more fragile (anything that stomps on the unauthenticated file also stomps on the authenticated file) but is a bit faster and reduces the number of inodes consumed by a large data collection. At the moment, copying is the default behavior, but this may change in the future. Values: true or false. Default: false trust-anchor:: Specify one RPKI trust anchor, represented as a local file containing an X.509 certificate in DER format. Value of this option is the pathname of the file. No default. trust-anchor-locator Specify one RPKI trust anchor, represented as a local file containing an rsync URI and the RSA public key of the X.509 object specified by the URI. First line of the file is the URI, remainder is the public key in Base64 encoded DER format. Value of this option is the pathname of the file. No default. ***** Post-processing rcynic's XML output ***** The distribution includes several post-processors for the XML output rcynic writes describing the actions it has taken and the validation status of the objects it has found. **** rcynic-html **** Converts rcynic's XML output into a collection of HTML pages su
[[PageOutline]]

[[TracNav(doc/RPKI/TOC)]]

= Building a DRLng Certificate Authority on Ubuntu Xenial =

I wanted to build a DRLng (rrdp, integrated root CA, seriously reworked
and meaner and leaner) Certificate Authority.

* I prefer Ubuntu these days.
* I wanted to build it on Ubuntu Xenial because Xenial has the upgraded
  TLS for rrdp.

== System Requirements ==

I built the following:

* 32GB of hard disk, enough to leave headroom unless you plan a LOT of
  certificates, as in thousands;
* 2GB or RAM, as it still is a bit of a RAM hog; and
* One CPU should be enough to start.
* The server must not have an AAAA DNS RR unless it has working IPv6
  connectivity.

== Xenial Install ==

* 
  [http://releases.ubuntu.com/16.04/ubuntu-16.04-server-amd64.iso 16.04 Ubuntu Xenial LTS 64-bit server]
* I do a fairly basic install, OpenSSH, basic utilities, and grub
* apt update and apt dist-upgrade of course
* I install automatic updates, emacs-nox, ntp, ... with ansible.  Note that ansible requires python2 and xenial installs python3.  So I had to install python2.7

I am lazy and log in as root as pretty much everything I do is going to
require being root.  If you like sudo, then just prefix a lot with it.

== Install the Basic RPKI CA and RP Software ==

You should only need to perform these steps once for any particular
machine.

Add the GPG public key for this repository (optional, but APT will whine
unless you do this):
{{{
# wget -q -O - http://download.rpki.net/APTng/apt-gpg-key.asc | sudo apt-key add -
}}}

Configure APT to use this repository (for Ubuntu Trusty systems):
{{{
# wget -q -O /etc/apt/sources.list.d/rpki.list http://download.rpki.net/APTng/rpki.trusty.list
}}}

Update available packages:
{{{
# apt update
}}}

Install the software:
{{{
# apt install rpki-rp rpki-ca
}}}

500kg of packages will be installed.  The daemons should also be started.
{{{
# /bin/ps axu | grep rpki | grep -v grep
rpki      5250  0.0  0.4 308040  8404 ?        Sl   07:37   0:00 (wsgi:rpkigui)    -k start
rpki      5436  0.0  0.4  45184  9380 ?        Ss   07:37   0:00 /usr/bin/python /usr/lib/rpki/rpki-nanny --log-level warning --log-directory /var/log/rpki --log-rotating-file-hours 3 --log-backup-count 56
rpki      5437  1.1  2.2 220204 45584 ?        S    07:37   0:00 /usr/bin/python /usr/lib/rpki/irdbd --foreground --log-level warning --log-timed-rotating-file /var/log/rpki/irdbd.log 3 56
rpki      5439  1.1  2.0 206428 42220 ?        S    07:37   0:00 /usr/bin/python /usr/lib/rpki/pubd --foreground --log-level warning --log-timed-rotating-file /var/log/rpki/pubd.log 3 56
postgres  5499  0.0  0.7 302016 15272 ?        Ss   07:37   0:00 postgres: rpki rpki [local] idle
}}}

== Minimal Configuration ==

This example install uses the server hostname `ca.rg.net`.  Any
use of that hostname below will have to be replaced with your host's
name, of course.

=== Relying Party - rcynic ===

The RP (Relying Party) software should have installed and should be
running.  You can test it by browsing to https://ca.rg.net/rcynic/.  It
uses a self-signed TLS certificate; you can be lazy and decided to
accept it as opposed to installing a real one.  If you want to use a
Lets Encrypt certificate, you might try
[https://wiki.rg.net/AcmeTinyUbuntu this homegrown recipe using acme_tiny.py],
which will require a bit of hacking as the rpki package
puts apache credentials in an odd place.

!!!!!!!!!  THE RCYNIC PAGE IS EMPTY  !!!!!!

The rcynic web page has not populated yet because the cron job to
populate is generated for a socially polite cache which fetches once an
hour.
{{{
# crontab -l -u rpki
MAILTO=root
41 * * * *      exec /usr/bin/rcynic-cron
}}}
Do not change this now as it would place an asocial load on the global
RPKI.

If you plan to use the rpki-rtr protocol to feed a router from the RP
cache you just installed, check `/etc/xinetd.d/rpki-rtr` to be sure the
port number is 323, the IANA assigned port, as opposed to some old hacks
that were used pre [http://www.rfc-editor.org/rfc/rfc6810.txt RFC 6810].
{{{
# cat > /etc/xinetd.d/rpki-rtr << EOF
service rpki-rtr
{
    type           = UNLISTED
    flags          = IPv4
    socket_type    = stream
    protocol       = tcp
    port           = 323
    wait           = no
    user           = rpkirtr
    server         = /usr/bin/rpki-rtr
    server_args    = server /var/rcynic/rpki-rtr
    }
EOF
}}}

If you have to change it, remember to
{{{
# systemctl restart xinetd
}}}

The configuration for rcynic is in `/etc/rpki.conf`.  Note that it
says to use the trust anchors in the directory
`/etc/rpki/trust-anchors`.  You may want to change the set of trust
anchors if you have unusual requirements.

=== CA Configuration - rpki.conf ===

`/etc/rpki.conf` is the core configuration file for the CA.  You need to
make very minimal changes.  If you want an explanation for all the
options, go to https://trac.rpki.net/wiki/doc/RPKI/CA/Configuration.
Get coffee first.

`handle` is generated as `ca_rg_net` or whatever.  You may want to
change it to something more intuitive such as `testCA` or whatever you
like.  You do not really need to do this, but let's assume you do.  I
changed it to `RGnet`, as I was creating a CA for RGnet's resources.

The `handle` in rpkic.conf is a historical relic (dating back to the
`myrpki.xml` interface, circa 2008).  It's become just the default for
`-i` / `--identity` / `select_identity` and may eventually go away
completely.

If you may offer publication services to other CAs, you will want to put
the contact email in `pubd_contact_info`.

Observe that the `publication_base_directory` expands/decodes to
`/usr/share/rpki/publication`.  Similarly, `bpki_servers_directory`
decodes to `/usr/share/rpki`.

That is it for configuration of `/etc/rpki.conf`!

=== rsyncd Configuration ===

Next, you want to get the rsync daemon working.  First you need to tell
the rsync daemon what it should serve.  So configure `/etc/rsyncd.conf`
as follows:

{{{
# cat > /etc/rsyncd.conf << EOF
uid             = nobody
gid             = rpki

[rpki]
    use chroot          = no
    read only           = yes
    transfer logging    = yes
    path                = /usr/share/rpki/publication
    comment             = RPKI publication

# the following is only of you plan to run a root CA
[tal]
    use chroot          = no
    read only           = yes
    transfer logging    = yes
    path                = /usr/share/rpki/rrdp-publication
    comment             = altCA TAL
EOF
}}}

Then tell xinetd to run the rsync deamon when asked and then to restart
xinetd
{{{
# cat > /etc/xinetd.d/rsync << EOF
service rsync
{
    disable         = no
    socket_type     = stream
    port            = 873
    protocol        = tcp
    wait            = no
    user            = root
    server          = /usr/bin/rsync
    server_args     = --daemon
    log_on_failure  += USERID
}
EOF
}}}

Remember to
{{{
# systemctl restart xinetd
}}}

== CA Data Initialization ==

The remaining configuration is done using the RPKI software itself.

=== Starting Services ===

Before configuring the CA daemon and database, you should first restart the
daemons.
{{{
# systemctl restart rpki-ca
}}}
You should see the daemons running
{{{
# /bin/ps axu | grep rpki | grep -v grep
rpki      5250  0.1  2.7 546316 57316 ?        Sl   07:37   0:00 (wsgi:rpkigui)    -k start
rpki      5597  0.0  0.3  25348  7132 ?        Ss   07:42   0:00 /usr/bin/python /usr/bin/rcynic-cron
rpki      5598 25.6  5.7 287132 116880 ?       R    07:42   1:44 /usr/bin/python /usr/bin/rcynic
postgres  5601  9.9  4.4 305024 91336 ?        Rs   07:42   0:40 postgres: rpki rpki [local] idle
rpki      7183  0.0  0.4  45184  9440 ?        Ss   07:48   0:00 /usr/bin/python /usr/lib/rpki/rpki-nanny --log-level warning --log-directory /var/log/rpki --log-rotating-file-hours 3 --log-backup-count 56
rpki      7184  4.0  2.2 220140 45848 ?        S    07:48   0:00 /usr/bin/python /usr/lib/rpki/irdbd --foreground --log-level warning --log-timed-rotating-file /var/log/rpki/irdbd.log 3 56
rpki      7186  3.7  2.0 206424 42308 ?        S    07:48   0:00 /usr/bin/python /usr/lib/rpki/pubd --foreground --log-level warning --log-timed-rotating-file /var/log/rpki/pubd.log 3 56
postgres  7193  0.0  0.6 302016 13104 ?        Ss   07:48   0:00 postgres: rpki rpki [local] idle
}}}

=== Initializing the CA ===

The command utility, `rpkic` is a CLI for dealing with the CA.  This
example uses it instead of the GUI, especially for initial setup, as it
is easier to copy and paste into a wiki.  The CLI has tab completion,
and the other features offered by readline().

It makes life easier if you do all this in a sub-directory to keep it
all together.  Also, files are written and read from the current
directory, often with code running under the uid of rpki.  So make the
director writiable by that uid.
{{{
# mkdir CA-data
# chown rpki CA-data
# cd CA-data
}}}

rpkic has the concept of the current identity.  Initially, it starts
with the identity from the handle in `/etc/rpki.conf`, RGnetCA in this
example
{{{
# rpkic
rpkic>
}}}

Before you do anything else, you need to initialize the CA.  Note that
we now use `create_identity` as opposed to `initialize`.  As mentioned
previously, for the moment the identity should be the same as the
`handle` in /etc/rpki.conf.
{{{
# rpkic
# rpkic create_identity RGnet
Wrote /root/CA-data/RGnet.identity.xml
This is the "identity" file you will need to send to your parent
}}}

For testing, copy the identity to the publication point.
{{{
# rsync RGnet.identity.xml /usr/share/rpki/publication
}}}

As the publication point now has data, it is recommended that you test
it from a remote system
{{{
% rsync rsync://ca.rg.net/rpki/RGnet.identity.xml
-rw-r--r--        1175 2016/04/24 16:53:53 RGnet.identity.xml
}}}

== Identity and Publication ==

You need to establish the BPKI relationship with your parent CA.  In
this case, that was RIPE


You may want to look below at the 
[https://trac.rpki.net/wiki/doc/RPKI/RRDPtestbed#UsingtherpkicCLIinsetupphase Using the rpkic CLI in setup phase]
for a general description of the provisioning steps.

=== The !Identity/Repository Handshake ===

I browsed to
[https://my.ripe.net/#/provisioning/non-hosted RIPE's provisioning page]
and uploaded /root/CA-data/RGnet.identity.xml and received back
issuer-identity-20160513.xml

I used that file to configure my server's view of its parent
{{{
# rpkic configure_parent issuer-identity-20160513.xml 
Parent calls itself '3336711f-25e1-4b5c-9748-e6c58bef82a5', we call it '3336711f-25e1-4b5c-9748-e6c58bef82a5'
Parent calls us 'f1400649-ab90-4332-b7e3-3da6b7e44cdb'
Wrote /root/CA-data/RGnet.3336711f-25e1-4b5c-9748-e6c58bef82a5.repository-request.xml
This is the file to send to the repository operator
}}}

The CA will need a repository, and we are assuming that we
will also host it.  So it should accept its own offer made above
{{{
# rpkic configure_publication_client RGnet.3336711f-25e1-4b5c-9748-e6c58bef82a5.repository-request.xml 
This might be an offer, checking
We don't host this client's parent, so we didn't make an offer
Don't know where else to nest this client, so defaulting to top-level
Client calls itself 'RGnet', we call it 'RGnet'
Wrote /root/CA-data/RGnet.repository-response.xml
Send this file back to the publication client you just configured
}}}

And then I configured the repository using the response from above
{{{
# rpkic configure_repository RGnet.repository-response.xml
Repository calls us 'RGnet'
No explicit parent_handle given, guessing parent 3336711f-25e1-4b5c-9748-e6c58bef82a5
}}}

You can see if it is publishing, maybe using a bit of coercion 
{{{
# rpkic force_publication
# ls -l /usr/share/rpki/publication
total 8
drwxr-xr-x 2 rpki rpki 4096 May 14 07:39 RGnet/
-rw-r--r-- 1 root root 1175 May 14 07:10 RGnet.identity.xml
}}}

If the publication sub-directory is not there, go work on something else
for a while and come back.

=== The GUI Should Now Work ===

One simple test is to try the GUI.  But first you need to set up the GUI
superuser password.  [ insert lecture on strong passwords ] 
{{{
# rpki-manage createsuperuser
Username (leave blank to use 'rpki'): RGnet
Email address: randy@psg.com
Password: 
Password (again): 
Superuser created successfully.
}}}
and write it down somewhere safe.

Then you can point your browser at `https://ca.rg.net`, and you should
see the login page.  Enter the user 'RGnet' (per above) and the password
from createsuperuser above.  This should take you to RGnet's dashboard.

== Using the rpkic CLI in setup phase ==

See the [[..|introduction to the user interfaces]] for an overview of
how setup phase works.  The general structure of the setup phase in
rpkic is as described there, but here we provide the specific commands
involved.  The following assumes that you have already installed the
software and started the servers.

* The rpkic "initialize" command writes out an "identity.xml" file in
  addition to all of its other tasks.

* A parent who is using rpkic runs the "configure_child" command to
  configure the child, giving this command the identity.xml file the
  child supplied as input.  configure_child will write out a response
  XML file, which the parent sends back to the child.

* A child who is running rpkic runs the "configure_parent" command to
  process the parent's response, giving it the XML file sent back by
  the parent as input to this command.  configure_parent will write
  out a publication request XML file, which the child sents to the
  repository operator.

* A repository operator who is using rpkic runs the
  "configure_publication_client" command to process a client's
  publication request.  configure_publication_client generates a
  confirmation XML message which the repository operator sends back to
  the client.

* A publication client who is using rpkic runs the
  "configure_repository" command to process the repository's response.



== Creating a New Root Authority ==

If you also need to be a CA for private address space, legacy space ARIN
will not certify, etc. you will want to create a root CA.

{{{
# rpkic configure_root
Generating root for resources ASN: 0-4294967295, V4: 0.0.0.0/0, V6: ::/0
Wrote /root/CA-stuff/altCA.altCA.repository-request.xml
This is the file to send to the repository operator
}}}
creates a weird kind of parent object, gives you back the XML for
repository setup (same as it did before, difference is just the
implementation).

configure_root can take an optional --resources argument which
configures the set of resources for the root to hold.  As you can see,
by default it's everything (0-4294967295,0.0.0.0/8,::/0).

=== Extract Root Certificate and TAL ===

There are two new commands to extract root cert and TAL:
{{{
# rpkic extract_root_certificate
# rpkic extract_root_tal
}}}

The latter is a bit iffy in the sense that it has no way of knowing
how you really set up all the things beyond its direct control: the
TAL it generates should be correct if you used the default setup, but
if you did something weird (eg, in your Apache or rsyncd
configuration) it might have the wrong URIs, and it has no real way of
knowing what you did.

Both certificate and TAL will be written to names derived from the
g(SKI) of the certificate, in the current directory (.).

You can rename the TAL to anything you like, but you should preserve
the g(SKI) filename of the certificate, because that's what the TAL
will be expecting to find.

Note that RRDP does *not* help with publication of the root
certificate (the root certificate is how the RP finds RRDP, not the
other way around), so you'll need to put a copy of the root
certificate in the location named by the HTTPS URI in the TAL
(/usr/share/rpki/rrdp-publication/ in the default Ubuntu setup).
generated by cgit v1.2.3 (git 2.25.1) at 2025-05-11 21:47:06 +0000