Managing device profiles

Defining a device profile

  1. From the sidebar on any YANG Suite page, select “Setup → Device profiles”.
  2. On the newly loaded page, select “New Profile.” A form will appear for you to enter the device information into.
  3. Enter a name for this device profile.
  4. Fill in all of the required fields under “General device information.” The address, username, and password you enter here will be used as default values for any specific connection method (SSH, NETCONF, etc.).
  5. For “Device supports the following,” check all of the connection methods that your device supports (SSH, NETCONF, etc.)
  6. Each of these methods will use method-specific defaults (e.g., port 22 for SSH) plus the parameters you entered under “General device information.” If you want to change any of these defaults, select the appropriate tab (such as “NETCONF”) to display its options, and make changes as needed to override the inherited defaults.
  7. Once this is done, you may use the “Check connectivity” button to confirm that the device is reachable by ping and by the access mode(s) you have enabled. This will take a moment then report the results of this check. If any checks failed, you should investigate to determine why and make corrections to the device profile as needed.
  8. Once you are satisfied that the device profile is properly defined, select “Save new device profile” to save this profile.
  9. You can now use this saved profile wherever YANG Suite requires one, such as downloading YANG modules from a device or sending NETCONF RPCs to a device.

Creating a Default Repository and Yangset

When first setting up a device profile, the next step many users do is download all YANG files from the new device creating a repository, and then creating a Yangset carved out of the new repository. By clicking on “Create Default Repository and Yangset” the download begins, a repository is created, and a Yangset containing all the YANG files in the repository is created. This allows the user to go right to work with an available Yangset.

Managing existing device profiles

From the same “Setup → Device profiles” page, you can manage the existing device profiles. Select any device profile from the list on the right side of the page, and you can then re-check its connectivity, make changes to it, clone it into a new device profile, or delete it if no longer needed.

Setting up YANG Suite TLS/SSL

A user can use any naming convention they want for cryptography keys and certificate files, so it is best to have a general understanding of them. We will not go into the different types of encryption, but basically, you want to use the strongest possible that both the client and device can understand.

Public Certificate Authority

  • TLS Root Key – openssl key used to create TLS Root Certificate
  • TLS Root Certificate – Common certificate created using the TLS Root Key (used as the common link between a device and a client certificate).
  • TLS Root Chain – A list of TLS Root Certificates (allows for multiple certificates to authenticate against)

Client (for example, YANG Suite)

  • TLS Client Key – The openssl key used to create the TLS Client Certificate
  • TLS Client Certificate – Certificate created using the TLS Client Key and the TLS Root Certificate

Device (for example, Cisco router)

  • TLS Device Key – openssl key used to create TLS Device Certificate
  • TLS Device Certificate – router (referred to as “device”) certificate which is created using TLS Device Key and TLS Root Certificate.

In a real world setting it is likely that the TLS Root Certificate or TLS Root Chain is stored on public root authority servers and not on the Cisco router itself.

TLS Host Override

When creating a certificate, you are prompted for input such as City, State, etc.. When it gets to CN (common name) you can enter the IP Address or the FQDN (host/domain name). If you setup your certificate to use the FQDN, the connection to a third party will authenticate against that. If the server hosting the TLS Root Certificate or Chain cannot associate the requesters IP Address to the FQDN, the connection is refused.

So should I set the CN to an IP Address on my certificate? Sure, if you are confident the IP Address will not change as a result of using DHCP or a VPN connection and server hosting the root receives my request on the same IP Address.

So should I set the CN to a FQDN? Sure, if the FQDN can be associated to the IP Address by a DNS server, or from the /etc/hosts file on the server hosting the root.

So should I just leave CN blank? Sure, if you do not enter a challenge password when generating the client or device certificate.

What do we end up with?

A TLS Root Certificate that can be validated by 2 different keys. The Root certificate authority can now act as a go-between for 2 devices, eventually authorizing their connection.

Is YANG Suite Setup Overkill?

Well, yes, kind of. If you think about it, if the client has the TLS Root Certificate or Chain, the client can use that to authenticate a device connection if the device has a certificate created using the same TLS Root Certificate or Chain. The YANG Suite client can actually make a successful connection to the device having only the TLS Root Certificate or Chain. But, by having all 3 files available, this allows YANG Suite to act as a client, a root authority, or a device.