In the directory /cf/var/db/certs/common you should see at least the following two subdirectories:

drwx------  2 root  wheel  512 Jul 20 16:14 key-pair
drwx------  2 root  wheel  512 Jul 20 16:16 local

In the key-pair directory you should see files for each of your key-pairs, eg. self-cert.priv. In the local directory you will find the actual certificates, eg. self-cert.cert. Both the key-pairs and certificates are stored in binary DER format, which can be read by OpenSSL and converted to the more universal base64-encoded PEM format.

Private keys should really be left alone where they are on the Juniper, but you can safely copy the certificate to other locations, since it does not contain any private key material. Simply scp the certificate file to somewhere that has the OpenSSL tools installed, then use “openssl x509” to read the certificate:

daniel@thinkpad:~$ openssl x509 -in self-cert.cert -inform DER
-----BEGIN CERTIFICATE-----
MIIDSDCCAjCgAwIBAgIRAKybOo9tijNXkhgT9fe0ZFMwDQYJKoZIhvcNAQEFBQAw
TzELMAkGA1UEBhMCREUxJTAjBgNVBAoTHFNldmVudGggU2lnbmFsIEx0ZC4gJiBD
.....
co9vOYXqYv81xnIxg5I0brLqCzruKULy4zc6YHzJAGICMOw2wS9BwRkQUR1B2EZH
2QWUSn4Enj2JJkT3p044U8/q4BKdJ9V52mxQfA==
-----END CERTIFICATE-----

There you have it folks… a base64-encoded PEM-format public certificate.

A quick n’ dirty solution is to use an unmanaged switch, such as one of the numerous 8-port desktop switches from manufacturers such as D-Link, Netgear, Linksys etc. Configure its upstream switchport as a trunk port, thus allowing your required VLANs to pass tagged frames to your unmanaged desktop switch.

Wait a second, you say…. unmanaged switches can’t do trunk ports. How can an unmanaged switch understand VLAN frames?

It doesn’t need to. What is an 802.1q tagged frame, other than a standard 802.3 ethernet frame with four additional bytes inserted? These four additional bytes are the 802.1q VLAN ID field and 802.1p CoS field. As long as the unmanaged switch does not truncate frames to the 802.3 standard 1518 bytes, it will happily forward the 1522-byte 802.1q tagged frames just like any other. The last time I encountered a switch that would not forward these slightly “oversized” frames, was about four years ago… and it was a very cheap and nasty brand (name withheld to protect the innocent guilty).

This trick also comes in handy when you have a user with a two-port VoIP phone (such as most Cisco, Snom, Polycom etc phones), using a voice-VLAN, and the user requires more switchports than are currently available at his/her desk. Simply connect the 8-port unmanaged switch before the IP phone (ie. to the upstream port), and connect the IP phone to the unmanaged switch. The phone still gets it’s tagged voice-VLAN frames, the PC gets its untagged data-VLAN frames (tag-stripped if necessary by the IP phone), and the user has 6 other ports available to connect whatever… including, if necessary, other VLANs (so long as they’re tagged, and the end device can work with tagged frames, since the unmanaged switch won’t strip the 802.1q tag).

Beware though, this should only ever be used as a temporary measure, since it does open a few security holes. If the “allowed VLANs” is not carefully configured on the upstream port, the opportunity exists to VLAN-hop, or flood traffic into other VLANs. And of course, since the unmanaged switch is, well, unmanaged, there is no individual “allowed VLANs” security on those 8 ports. All ports are effectively the same as that one upstream trunk port.

Have you used this method before? What brand/model unmanaged switch did you use? What were your experiences with it, and did you encounter any problems?

set ssh version v2
set ssh enable
set scp enable

And of course, you need to enable ssh management on the interface you’re going to connect to the device on:

set interface ethernet0 manage ssh

Once that has been done, from your PC, try the following:

scp netscreen@device-hostname:ns_sys_config ssg.cfg

And you should then have a file called ssg.cfg in that directory. Once again, simple when you know how.

It is also possible to load RSA/DSA keys against ScreenOS usernames, so that password-less login for ssh/scp can be utilised, allowing this method to form the basis of automated config backups.