Cisco Developer Sandbox — Self-Signed SSL Certs Disliked by Chrome

Cisco have some great free courses around network programability, even providing hosted sandboxes to play with over at https://learninglabs.cisco.com/

I’m going through some now for my next engagement and can’t recommend them highly enough; succinct yet covering the important details; they’re great for someone with existing experience in programming and networking but not Netconf, Yang et al.

However — I hit a roadblock on the RESTCONF track, due to the fact that the hosted sandbox uses a self-signed SSL cert, which Chrome (hence Postman) doesn’t like. In Postman this looks like so:

Note the point about SSL connections in the “Why this might have happened”. This is the issue. Visiting the page in Chrome:

Your connection is not private
Attackers might be trying to steal your information from ios-xe-mgmt.cisco.com (for example, passwords, messages or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID

To remedy this, things I tried which did not work

• copying the cert to /usr/local/share/ca-certificates/ then dpkg-reconfigure ca-certificates
• chrome://settings/ add cert trusted
• certutil — including messing around with versions, sqlite etc

Eventually I did what I should’ve done off the bat, and opened Chrome dev tools, where I could see the following:

Sure enough, since April 2017 (v58) Chrome requires Subject Alternative Name. If I had control over the cert no problem, just generate a new one with such. However in the hosted sandbox, I do not.

Apparently you can (could?) disable this in Chrome settings, but that’s generally less secure, plus no fun.

I needed a way to tunnel Postman/Chrome to the sandbox, via a trusted place, with that tunnel endpoint trusting the dodgy self-signed cert, so that Chrome didn’t have to.

One possible way would be mitmproxy, a cool tool which I’ve been playing around with lately. However simpler is the excellent socat. Simply sudo apt install socat then:

socat TCP-LISTEN:9443,fork,reuseaddr,bind=127.0.0.1 OPENSSL:ios-xe-mgmt.cisco.com:9443,verify=0

This creates a tunnel listening on 127.0.0.1:9443, and forwarding to the cisco sandbox 9443 via SSL. I tried to chuck this command into the normally-excellent explainshell.com, however it seems it doesn’t support socat so well. In lieu of this, a brief explanation of the args used:

• fork to handle multiple (re)connections and don’t close after handling just one request
• reuseaddr binds to the port with SO_REUSEADDR option so that subsequent runs can bind to the port even if it’s in state TIME_WAIT (happens after we ctrl-c)
• on the destination, verify=0 to ignore the self-signed cert. Also note

OK great. To test, let’s try going there in the browser:

Looks good.

Now we just need to update Postman to use our proxy. In the top right, click the ⚙ icon and change the host from ios-xe-mgmt.cisco.com to localhost:

Close, change the scheme from https to http (also ensure username and password use the environment vars as shown)

And bob’s our uncle.

Being the good netizen that I am, I’ve forked Cisco’s repo and submitted a PR. Until it’s merged you can obtain my version here: https://github.com/rdkls/dnav3-code/tree/fix/postman_restconf

Changes

• dev/tunnel-ssl-ios-xe-mgmt.cisco.com.sh — New script to stand up the socat tunnel from localhost to the always-on sandbox
• DevNet Learning Labs- Intro to Model Driven Programmability.postman_collection.json — Set ‘Authorization:’ header correctly (some requests were using “cm9vdDpjaXNjbzEyMw==” (“root:cisco123”)), switch to plain http (since now via socat tunnel), remove request.auth elements since with new postman version they were causing auth to get reset when request made —and now we are hardcoding Authorization: header
• DevNet Sandbox RESTCONF Always On.postman_environment.json —host=localhost (use tunnel), remove username and password since no longer used

Happy hacking!