Add Danish NemID X.509 public certificate to RIPE Database


If you ever used the RIPE Database.

You know the following RIPE Maintainer Authentication methods is possible.

  1. SSO (a.k.a. single sign on)
  2. key-cert (GnuPG keys + X.509 certificate)
  3. MD5 encrypted passwords


  1. IF you have the danish NemID follow the guidelines here to configure NemID on your computer. And then for you email program.
  2. Go find your public certificate here and download it.
  3. Open the certificate locally on your computer and prepend every line with ‘certif: ‘ so it looks the example below. Remember the key-value pairs:
    • key-cert: auto
    • mnt-by: xyz
    • source: ripe


  • from older RIPE documentation.
key-cert: AUTO-1
certif: -----BEGIN CERTIFICATE-----
certif: Ew91ay5idC50ZXN0LXVzZXIxLzAtBgkqhkiG9w0BCQEWIHRlc3QtdXNlckBsaW51
certif: AQEArv3srxyl1QA3uS4dxdZbSsGrfBrMRjMb81Gnx0nqa6i+RziIf13lszB/EYy0
certif: PgLpQFdGLdhUQ52YsiGOUmMtnaWNHnEJrBUc8/fdnA6GVdfF8AEw1PTfJ6t2Cdc9
certif: 2SwaF+5kCaUDwmlOgbM333IQmU03l3I1ILs32RpQyZ+df/ovHNrVzeLc2P59isac
certif: bfjM2S0SXPQzHjuVLH40eOgVuXA/5LAYs51eXqwtKszSxFhqekf+BAEcRDrXmIT4
certif: e3zfiZOsXKe0UfaEABgHUMrYjsUCJ8NTMg6XiVSNwQQmXCdUbRvK7zOCe2iCX15y
certif: IE5DQyBDQTAdBgNVHQ4EFgQUzdajNaRorkDTAW5O6Hpa3z9pP3AwgZsGA1UdIwSB
certif: d2FyZSBQS0kgVGVzdGluZzEfMB0GCSqGSIb3DQEJARYQc29mdGllc0ByaXBlLm5l
certif: dIIBADANBgkqhkiG9w0BAQQFAAOBgQByg8L8RaiIz5k7n5jVwM/0oHSf48KRMBdn
certif: YdN2+eoEjVQbz48NtjbBTsOiUYj5AQWRHJrKtDQ+odbog0x7UsvhXjjBo/abJ6vI
certif: AupjnxP3KpSe73zmBUiMU8mvXLibPP1xuI2FPM70Y7fgeUehbmT7wdgqs7TEtYww
certif: PeUqjPPTZg==
certif: -----END CERTIFICATE-----
mnt-by: YOUR-MNT
source: RIPE

Afterwards you should be able to sign emails send to “RIPE Database” <> with your NemID certificate and the updates gets approved if your maintainer has authorization over the object you try to create/modify/delete.


My X.509 certificate

How-to VPN: Private Internet Access (PIA) and MikroTik Router

⚠ Information in this post is outdated since the launch of PIA’s ‘Next-Gen’ VPN network in 2020, sunsetting the then-existing set-up

First create a vpn profile to use when creating l2tp/pptp connections
to privateinternetaccess.

/ppp profile add change-tcp-mss=yes \
comment="PIA VPN" \
dns-server=, \
name=privateinternetaccess only-one=no \
use-compression=no use-encryption=required \
use-ipv6=no use-mpls=no use-upnp=no

Create the l2tp interface

/interface l2tp-client add \
comment="PIA VPN Netherlands" \ \
disabled=no name=pia-de-l2tp \
profile=privateinternetaccess \
user=[l2tp-username] \
  • [l2tp-username] Your PIA username for l2tp/pptp/socks connections beginning with ‘x’ (not ‘p’!)
  • [l2tp-password] Your PIA password for l2tp/pptp/socks connections

Create a firewall mangle rule to mark IPv4 traffic we want to
go through the VPN.

/ip firewall mangle add \
action=mark-routing \
chain=prerouting \
comment="PIA VPN Netherlands" \
new-routing-mark="PPTP RM" \
passthrough=yes \
    • <li


    Fx. or

Create the NAT rule and tell it to use the VPN interface.

/ip firewall nat add \
action=masquerade chain=srcnat \
comment="PIA VPN Netherlands" \

Create a corresponding default route to match the previous NAT
rule. Which only get used when IPv4 traffic has been marked with

/ip route add \
comment="PIA VPN Netherlands" \
disabled=yes distance=1 \
gateway=pia-de-l2tp routing-mark="PPTP RM"

Now you should see traffic from clients in the IPv4 range
of [ip-range-to-forward-through-vpn] go through the VPN.

NB: If you want to use another country apart from Netherlands. Check out Private Internet Access list of locations here: PIA VPN Tunnel Network

Git Rebase Interactive

Being new to git. You will inadvertently struggle.

  1. Having opened a pull request (PR), leaving the PR hanging for a while, picking it up Y time later, with several changes have happened in the upstream branch. You will often find yourself in need of using git rebase upstream/master ((
  2. After having rebased recent commits upon the upstream/master branch. You might want to squash your commits together, to create a cleaner pull request, and to avoid (un)intentionally blotting the git-history with miscellaneous commits, imagine:
    $ git log --graph --pretty=format:'%Cred%h%Creset %s'
    * 77464f9 Update 'filename1.txt'
    * 2a7894b Update 'File 2.txt'
    * 27a44c6 Add 'File 2.txt'
    * 4bc179b Add 'filename1.txt'
    * 8757b20 Initial commit

    Can be reduced

    pick  = use commit
    reword  = use commit, but edit the commit message
    edit  = use commit, but stop for amending
    squash  = use commit, but meld into previous commit
    fixup  = like "squash", but discard this commit's log message
    break = stop here (continue rebase later with 'git rebase --continue')
    drop  = remove commit
    $ git rebase --interactive 8757b20
    reword 4bc179b Add 'filename1.txt'
    fixup 27a44c6 Add 'File 2.txt'
    fixup 2a7894b Update 'File 2.txt'
    fixup 77464f9 Update 'filename1.txt'
    $ git log --graph --pretty=format:'%Cred%h%Creset %s'
    * 255c889 Add 'filename1.txt', and 'File 2.txt'
    * 8757b20 Initial commit
  3. If in need of deciding which commit to squash together, and were to edit the commit message. Using git rebase --interactive (commit-hash, remote-name/branch-name, or branch-name) is the lifeline.

Remember, the commit hash will change when using git rebase action. Force pushing to the remote branch to replace its contents is necessary.
git push remote-name local-branch-name:remote-branch-name --force
(e.g. git push origin master-squashed-commits:master --force).

But this approach is the recommended way in regards to using git pull-requests. Any existing pull-requests against a branch you have on your fork of the upstream repository. Will automatically use the latest available information in your fork’s branch.