Certificate on Yubikey4

This instruction is primarily intended for my own documentation, but published here it can serve others as well.

My personal (client) certificate was generated using the Mozilla Firefox browser. To move the certificate key combination to my Yubikey I had to make a backup of the certificate. In Mozilla you are able to create a P12 backup of the certificate including key (remember the password!).

1. Extract certificate and key

$ openssl pkcs12 -in person.p12 -nocerts -out privateKey.pem
Enter Import Password:                                          
Enter PEM pass phrase:                                          
Verifying - Enter PEM pass phrase:                              
$ openssl pkcs12 -in person.p12 -clcerts -nokeys -out publicCert.pem
Enter Import Password:

2. Remove password on the key

$ openssl rsa -in privateKey.pem -out privateKey-nopassword.pem
Enter pass phrase for privateKey.pem:
writing RSA key

3. Import the key

$ ykman piv import-key -P ****** --pin-policy ONCE 9a privateKey-nopassword.pem

4. Import the certificate

$ ykman piv import-certificate -P ****** 9a publicCert.pem
Enter password to decrypt certificate:
Aborted!

Huh? That’s strange. The certificate is not password protected. It appears there are some attributes placed above the actual certificate. Remove those lines so that ‘—–BEGIN CERTIFICATE—–‘ is on top.

5. Import the certificate again

$ ykman piv import-certificate -P ****** 9a publicCert.pem

6. Cleanup

Since the certificate and key are now on the smartcard you can safely delete them from disk:

$ rm publicCert.pem privateKey.pem person.p12

As soon as you configure your Yubikey as smartcard for Firefox you can also remove the certificate from the Mozilla Certificate store.

Done!

For reference, this instruction was created on a Arch Linux installation.

Baby jumbo frames on VDSL by XS4ALL

Last week I acquired a new modem because the old one supplied by the provider was acting strange and I wanted it. The new modem is a Cisco 887VA router equipped with a VDSL2/ADSL2+ interface so that it could replace the previous Fritz!box. A day after I had finished the setup I noticed some unusual things which eventually led to the conclusion that packet fragmentation was occurring. In my search for an answer I learned that the Point-to-Point protocol (PPP) needs 8 bits which need to be subtracted from the default MTU of 1500. So configuring an MTU size of 1492 for the Dialer0 interface and altering the max segment size ‘ip tcp adjust-mss 1452’ on the internal VLAN interface did the trick.

But, then I stumbled upon a service page of my provider stating (in Dutch):

RFC4638 wordt ondersteund op ons netwerk. Dit betekent dat u als klant een MTU van 1500 kunt gebruiken als uw router RFC4638 ondersteunt.

So it’s possible to use a MTU size of 1500 if the router is able to do so. In the past I have played with MTU sized 9000 (called Jumbo frames), so 1512 is a baby.

It took some time to figure out how, but eventually came up with the following:

!
interface Ethernet0
 mtu 1512
 no ip address
!
interface Ethernet0.6
 encapsulation dot1Q 6
 pppoe enable group global
 pppoe-client dial-pool-number 1
 pppoe-client ppp-max-payload 1500
!
interface Dialer0
 no mtu 1492
!
interface Vlan2
 no ip tcp adjust-mss 1452
!

Want to follow the PPP negotiation proces, then execute to following (in enable mode):

debug ppp negotiation
clear ppp all
show logging

Time to test!

$ ping -c 3 -s 1472 www.xs4all.nl
PING www.xs4all.nl (194.109.6.92) 1472(1500) bytes of data.
1480 bytes from www.xs4all.nl (194.109.6.92): icmp_seq=1 ttl=61 time=6.18 ms
1480 bytes from www.xs4all.nl (194.109.6.92): icmp_seq=2 ttl=61 time=6.23 ms
1480 bytes from www.xs4all.nl (194.109.6.92): icmp_seq=3 ttl=61 time=5.96 ms

--- www.xs4all.nl ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 5.966/6.128/6.234/0.116 ms
$