Running a Publication Server¶
It is highly recommended to use an RPKI publication server provided by your parent CA, if available. This relieves you of the responsibility to keep a public rsync and web server available at all times.
If you need to run your own Publication Server using Krill, then we recommend that you use a separate Krill instance acting as a repository only. This setup allows for much easier reconfiguration (more on this below), and it allows that other CAs - for example a delegated CA for one of your business units also publish at this same Publication Server.
Configuring a Krill Repository¶
The Krill UI is not currently aimed at using Krill as a repository server. For example when visiting the UI of a Krill instance intended for use only as a repository and not as a CA, it will still prompt you on first use to create a CA. There is also no support via the UI for managing the repository, for example it is not possible via the UI to complete a child request to register with the repository.
Krill can be set up to run as a Publication Server through its configuration file. If enabled, the Publication Server is created on start-up. After this any updates to the configuration will NOT be reflected in the Publication Server.
For this reason you should double check the values used for the public URIs to your repository server carefully before the set-up. Using a dedicated Krill instance for the Publication Server will allow you to simply destroy and replace the instance should it have been misconfigured.
The easiest way to make a configuration file is by using krillc config to generate the required configuration for you. For example:
krillc config repo \ --server "https://rfc8183.example.net/" \ --token correct-horse-battery-staple \ --data ~/data/ \ --rrdp "https://rpki.example.net/rrdp/" \ --rsync "rsync://rpki.example.net/repo/" > krill.conf
Make sure that the
--server option reflects a base URI that your Krill CA
publication clients can reach, and make sure that this URI is exposed using
a proxy server that has a proper HTTPS certificate configured.
Make sure that the
--rsync options match the configuration of your
“Repository Servers” which make your repository available over HTTPS and rsync
to Relying Parties.
It would have been better to make the Publication Server configuration something that should be done run-time, as this would match more intuitively with the fact that the server, rrdp and rsync URIs cannot be changed through the configuration file.
In a future release of Krill we may do exactly that. But, even if we do it would be ill advised to allow changing these URIs at run time, as there would be no way for the Krill Publication Server to inform its publishers about any change.
So, in short, this needs to be set up correctly once. If it turns out to be wrong, then a new Publication Server should be set up and any existing publishers should be migrated as described below.
Proxy for Remote Publishers¶
Krill runs the RFC8181 Publication Server. Remote publishers, CAs which use your Publication Server, will need to connect to this under the /rfc8181 path under the service_uri that you specified in your server.
Make sure that you set up a proxy server such as NGINX, Apache, etc. which uses a valid HTTPS certificate, and which proxies /rfc8181 to Krill.
Note that you should not add any additional authentication mechanisms to this location. RFC 8181 uses cryptographically signed messages sent over HTTP and is secure. However, verifying messages and signing responses can be computationally heavy, so if you know the source IP addresses of your publisher CAs, you may wish to restrict access based on this.
Configuring Repository Servers¶
To actually serve the published content to Rsync and RRDP clients you will need to run your own repository servers using tools such as Rsyncd and NGINX.
Krill will write the repository files under the data directory specified in its configuration file:
$DATA_DIR/repo/rsync/current/ Contains the files for Rsync $DATA_DIR/repo/rrdp/ Contains the files for HTTPS (RRDP)
You can share the contents of these directories with your repository servers in various ways. It is possible to have a redundant shared file system where the Krill Publication Server can write, and your repository servers can read. Alternatively, you can synchronise the contents of these directories in another way, such as rsyncing them over every couple of minutes.
If you are using a shared file system, please note that the rsync
/current directory cannot be the mount point. Krill tries to write the
entire repository to a new folder under
$DATA_DIR/repo/rsync and then
renames it. This is done to minimise issues with files being updated while
relying party software is fetching data.
The next step is to configure your rsync daemons to expose a ‘module’ for your
files. Make sure that the Rsync URI including the ‘module’ matches the
rsync_base in your Krill configuration file. Basic configuration can
then be as simple as:
$ cat /etc/rsyncd.conf uid = nobody gid = nogroup max connections = 50 socket options = SO_KEEPALIVE [repo] path = /var/lib/krill/data/repo/rsync/current/ comment = RPKI repository read only = yes
For RRDP you will need to set up a web server of your choice and ensure that it
has a valid TLS certificate. Next, you can make the files found under, or copied
$DATA_DIR/repo/rrdp available here. Make sure that the public URI
to the RRDP base directory matches the value of
rrdp_service_uri in your
krill.conf file, or the
--rrdp option if you generated the
If desired, you can also use a CDN in front of this server to further reduce
your load and uptime requirements. If you do, make sure that the public URI
matches the directive in
krill.conf, because this will be used in your
RFC 8181 (publication protocol)¶
Make sure that your Krill Publication Server can be reached by your Krill CA
clients. The best way to do this, is by setting up a web server, similar to the
RRDP set up above, which proxies access to URIs starting with
the hostname you specified with the
--server option through to your Krill
Publishing in the Repository¶
As there is no UI support for this, you will need to use the command line interface using the krillc publisher subcommand to manage publishers.
This subcommand will allow you to add your Krill CA client’s RFC8181 Publisher Request XML, and obtain a Repository Response XML for it. From the client CA’s perspective this part of the process is exactly as described here.
To add the Krill CA client XML to your server use the following:
$ krillc publishers add --request <path-to-xml> [--publisher publisher]
--publisher is not specified then the publisher identifier handle will be
taken from the XML. Handles need to be unique. So, you may want or need to
override this - especially if you provide your Publication Server as a service
If successful this will show the response XML. But, you can also get this response XML for a configured publisher using the following:
$ krillc publishers response --publisher publisher
Migrating the Repository¶
If you find that there is an issue with your repository or, for example, you want to change its domain name, you can set up a new Krill instance for the new repository. When you are satisfied that the new one is correct, you can migrate your CA to it by adding them as a publisher under the new repository server, and then updating your CA to use the new repository.
Updating the repository of your Krill CAs is currently not possible using the UI, but you can archive this trough the command line interface connecting to your Krill instance that hosts your CA.
First you will need to get your CA’s Publication Request XML using the following:
$ krillc repo request
You then need to give this XML to your Publication Server, be it provided by a third party or managed by yourself as described above. After receiving the Repository Response XML you can then update your CA’s repository using:
$ krillc repo update --response <path-to-xml>
Krill will then make sure that objects are moved properly, and that a new certificate is requested from your parent(s) to match the new location. This scenario would also apply when your RIR starts providing a repository service. You can update your CA to start publishing there instead.