Generating RSA Private Key and Public Certificate for HTTPS

Products PTP
1

I had to post this since the PTPs now require users to generate their own key/certificate, rather than the device doing it for you. The manual offers almost no help in this regard, so here’s the process (feel free to modify) with free program OpenSSL. Please post that you’ve used this and maybe Cambium might add some official help to the manual. Configuration is a “recipe”; unless the ingredients change, it should never change! That’s what a manual is for. So we don’t have to hunt around for hours and hours.

These instructions based on code version 03-30 (25Jan2021).

Cambium requirements: “Upload the RSA Private Key and Public Certificate for the HTTPS interface using 2048-bit key size and SHA256. The certificate subject must be the ODU’s IP Address, for example 169.254.1.1. Input must be in Distinguished Encoding Rules (DER) format.”

DO THIS STEP BEFORE YOU CHANGE PASSWORDS or ENABLE SNMPV3.

And this is the only spot you can disable HTTP. If you try via the “Web-Based Management Page” it will also disable HTTPS.

Steps:

  1. Both radios must have the AES128 (or 256) license key applied in the radio to be able to do this. You can confirm by:
    a. Clicking on “Installation”, then “Continue to Installation Wizard”.
    b. The first page is where the license key is applied and at the bottom is a “Capability Summary”. It should say “License Encryption AES 128-bit”.

  2. Install OpenSSL for windows (if applicable) – the “Light” version and 64-bit or 32-bit as appropriate to your system (usually 64-bit these days) – should say something like “Win64 OpenSSL v1.1.1j Light”: https://slproweb.com/products/Win32OpenSSL.html

    Note - common OpenSSL commands:
    https://www.sslshopper.com/article-most-common-openssl-commands.html

  3. Open program “Win64 OpenSSL Command Prompt”.

  4. Execute the following commands in the command prompt; Replace IP address with the below commands with the radio IP you are using. Be sure to use “.” (dots) to ensure all fields but the IP address are BLANK. The IP address is entered into the “Common Name” field. Pre-generate the certificate and keys for BOTH radios before continuing on from this step.

    You will also need a password for the key generation; just make sure you write it down since you need to enter it multiple times. You will not need this password when managing the radios.

    <You can try to increase the certificate expiry; “-days 3650” gives us 10 years but would probably preferable to increase. e.g. 30 years or “-days 10950”. This is untested.>

    Also note: OpenSSL outputs PEM by default, so you must specify DER to output. You can validate your certificate file by opening it with notepad. If it’s gobbledygook it’s DER encoded. If it starts with “-----BEGIN CERTIFICATE-----” then it’s Base64 encoded (PEM). OpenSSL also requires a PEM key to generate a certificate (DER or PEM) so we still need the PEM key. That’s why the three OpenSSL steps:

Copy/paste commands:

openssl genrsa -aes128 -out cambium-192.168.1.20-key.pem 2048

openssl rsa -inform PEM -in cambium-192.168.1.20-key.pem -outform DER -out cambium-192.168.1.20-key.der

openssl req -x509 -sha256 -days 3650 -nodes -outform der -key cambium-192.168.1.20-key.pem -out cambium-192.168.1.20-crt.der

Example Output:

C:\Users\<user>\Downloads>openssl genrsa -aes128 -out cambium-192.168.1.20-key.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
................+++++
....................+++++
e is 65537 (0x010001)
Enter pass phrase for cambium-192.168.1.20-key.pem:
Verifying - Enter pass phrase for cambium-192.168.1.20-key.pem:

C:\Users\<user>\Downloads>openssl rsa -inform PEM -in cambium-192.168.1.20-key.pem -outform DER -out cambium-192.168.1.20-key.der
Enter pass phrase for cambium-192.168.1.20-key.pem:
writing RSA key

C:\Users\<user>\Downloads>openssl req -x509 -sha256 -days 3650 -nodes -outform der -key cambium-192.168.1.20-key.pem -out cambium-192.168.1.20-crt.der
Enter pass phrase for cambium-192.168.1.20-key.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:192.168.1.20
Email Address []:.

  1. Start on REMOTE radio first. Be aware that you’re on a timer and the system could log you out. You should be ready to move quickly at this point.

  2. Click “Security” then “Continue to Security Wizard” button

    Note: The capability to disable HTTP and enable both the wireless encryption and HTTPS is via the “Security Configuration Wizard”. You can enable wireless encryption in the “System->Configuration” (“System Configuration”) page but they make you do it here and overwrite the System Configuration page. It just means you end up doing it twice (more reboots and more risk).

  3. Click the “Generate Random Key” button for sections “Enter Key of Keys” and “Enter Random Number Entropy Input”.
    Note: The “Enter Key of Keys” will wreck your SNMPv3 configuration meaning you have to do it twice. That’s why we do this part first.

  4. Security banner:
    - Unauthorized Use Prohibited.

  5. Enable “display login information”

  6. Enter HTTPS Configuration – select the cert and key you generated (.der files). If it’s not in DER format you’ll get a “Invalid TLS public certificate file” error.

  7. Enter the wireless encryption setting as “TLS PSK 128-bit” (if it doesn’t show this option, then the AES-128 licensed was either not purchased or not applied or both).

  8. Have it generate a key and COPY IT. This key must match on BOTH radios (both ODUs or outdoor units).

    If it does not then you’ll lose access to the remote. Do the far side configuration first and the near side. Be aware that you’re on a timer and the system could log you out. So that’s why we pre-generate both radio’s certificates first.

  9. On the “Enter HTTP and Telnet Settings” set “HTTP Access Enabled” to “NO”.

    Note: We’ll leave telnet enabled in case we need to telnet locally from the router or because we’re locked out of HTTPS.

  10. On the page asking you to REBOOT, pause and start this process again with the near side radio then pause at the REBOOT page.

  11. Setup a ping to the far radio to confirm it all comes back up.

  12. Reboot the far side radio.

Author: https://www.textor.ca/trevor-textor-about-me/

1 Like
2

Thanks for that detailed post Trevor!

We think that PTP 670 provides some really excellent security features. The approach based on externally-generated certificates hasn’t changed over the lifetime of PTP 650 and PTP 670. However, we recognize that it is not straightforward to generate the required keys and certificates to configure HTTTPS, and perhaps some further guidance would be in order.

You’ve used a slightly different approach from what we normally use ourselves. We’ll review this in detail and respond in detail shortly.

Mark

1 Like
3

Excellent, thanks Mark. Much appreciated.

4

Unfortunately, I don’t have our preferred process for generating RSA keys and certificates ready for publication, but I’ll keep working on it. I should have something in the next few days.

Meanwhile, here are two observations:

Self-signed certificates

The process at the start of this topic generates a self-signed certificate. A self-signed certificate provides privacy in the HTTPS connection, but it doesn’t provide authentication, so a user cannot be certain that he/she is connected to the genuine ODU. It might be possible to restore the authentication function by adding the certificate to the browser’s trusted certificate store but that would be a cumbersome solution in a network with several ODUs and several management platforms.

Self-signed certificate normally trigger browser warnings. It’s never a good idea to ignore browser warnings, because they’re trying to tell us something important.

Instead, we prefer to create a local Certificate Authority and then use this CA to sign the individual certificates. In this case, we only need to add one Root CA certificate to the browser’s trusted certificate store. Of course, there are a few more Open SSL commands needed.

Subject Alternative Name

Until recently, browsers were able to process the subject of the certificate (in this case the IP address or DNS name) from the Common Name field, even though this has not been a part of the Internet standards for a long time.

Now browsers have tightened up here, and will only read the subject from the Subject Alternative Name (SAN) field. Browsers reject the certificates that we have previously been using.

It’s possible to create an X.509 with IP address in the SAN field using Open SSL. In fact, it got a great deal easier to do this in Open SSL 1.1.1. This is chiefly where I need to do a bit more work.

1 Like
5

Please see the Knowledge Database topics starting at Generate HTTPS Certificates for PTP 650/670 - Create the CA for a more detailed description of our preferred approach.

6

Hi Mark,

Really appreciate the focused and detailed response.

I’ve been working in/around security for over 20 years (SANS GSEC cert) and here’s my observation on Private Certificate Authority (AKA “Local CAs”):

In the 20 or so companies I’ve worked with, big and small, none of them had private CAs. So while I agree to your technical assessment, in-practice it’s hard to convince management of the expense. Network administrators (NA) typically manage 100s, if not 1000s, of devices and many of them have an HTTPS interface with self-signed certificates. You just get used to clicking through to the device via the browser warnings. Not to say that a NA could be tricked very easily. Then there is SSH which has a similar issue but less widely known and addressed.

The challenge in selling this to management comes down to budget and security priorities. Of the security priorities I’d say social engineering is probably #1 issue (requires training staff to mitigate) and #2 is physical security. I’ve seen plenty of large companies with satellite offices put tons of money into securing data centers and large city corporate offices just for the satellite offices to allow anyone off the street to come in and plug into the network (or password recovery the devices). It’s amazingly easy to just follow someone badging into a floor and sit down at an unlocked computer and/or install a keylogger.

So if encrypting management sessions and authenticating is somewhere down the list, possibly way down, what can be done? If Edward Snowden taught us anything, it’s that we should encrypt sessions at least, even if it’s not authenticated. Perhaps someday there will be a Let’s Encrypt initiative for all the devices needing management. Today Let’s Encrypt doesn’t work in this case.

[I’m very curious how Cambium came to be convinced to implement this level of security since it’s the first vendor I’ve come across to try this out.]

Interesting on the Subject Alternative Name (SAN) field, thanks for pointing that out.

I read through your “Configure HTTPS on PTP 670 - Create the CA” - has this been tested? The ODU is requiring a key in DER format, not PEM, so the key needs to be converted. Otherwise you get an “Invalid TLS public certificate file” error.

Cheers,

Trevor

7

Hi Trevor,

The Knowledge Base topic you mention describes how to generate the private key and self-signed certificate for a local CA. We’re then going to use that key to sign the actual ODU certificates. The CA private key will never be installed in an ODU. OpenSSL uses the PEM format as a default, so I thought it was simpler to keep the CA private key as a PEM.

You’re correct in saying that we need keys and certificates in the DER format to install in the ODU.

Best regards, Mark