Buy or Renew
Buy or Renew
NEW! Stay up-to-date on Cisco Secure Access: Software Release Notes and Announcements
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1259
Views
0
Helpful
4
Replies

VSM 7.7 SSL Certificate error

buildingblockvideo
Level 1
Level 1

‎02-22-2016 02:13 AM

Hi,

Any thoughts on solving this error when using the CameraControls api

curl SSL

and using the -k option the server returns

Missing SessionId header or security information.

Labels:
0 Helpful
4 Replies 4

Scott Olsen
Level 6
Level 6

‎02-22-2016 05:22 AM

Yup.  As indicated, you can tell curl to disregard the certificate issues with the -k switch. This works, but as you indicated, exposes another underlying issue.  The camera is still expecting the request to be from an authenticated session containing a valid *sessionID*.  There are a couple ways one could try to overcome this challenge;

1) Disable SessionID in the camera firmware so that a valid session (and therefore SessionID) is no longer required.  The option claims to be configurable via the camera firmware, but as I've mentioned in another thread, I personally have never had much success in getting it to acknowledge this setting.

2) Add the authentication functionality to your script and acquire a legitimate SessionID from the camera that can then be passed to the curl utility.

Hope this helps.

Cheers!

Scott Olsen Solutions Specialist Bulletproof Solutions Inc. Web: www.bulletproofsi.com
0 Helpful

buildingblockvideo
Level 1
Level 1
In response to Scott Olsen

‎02-22-2016 06:23 AM

Thanks for the pointers. 

Wouldn't it be easier if the server produced a valid Certificate rather than disabling a security feature and exposing all clients to risk?

So i need to use the same session id in the html header of the request that i used to generate the required token?

This surely makes the token useless if you have to send both anyway?

0 Helpful

Scott Olsen
Level 6
Level 6
In response to buildingblockvideo

‎02-22-2016 07:22 AM

Yes.  Instead of disregarding the warnings concerning the SSL certificate, you could certainly address them.  There are two ways to go about that and I suppose it would depend on the scope of your project which would make the most sense;

  1. Add the presented certificate from the Camera (or VSOM/VSMS server instance in this case?) to the Trusted Certificate store on the machine making the curl request.
  2. Re-cert the Camera/VSOM/VSMS server with certificate information signed by a CA that is already trusted (public CA, or enterprise PKI potentially?).

As for the SessionID, if that is being communicated via SSL (and not subject to a MITM interception/relay of some sort), it's going to be encrypted in the TLS/SSL tunnel, so not inherently useless.  

The -k option isn't causing all TLS/SSL encryption to be dropped... it's just telling curl to disregard that the certificate *authenticity* might not be up to scratch (signed by a trusted CA, proper date ranges, etc. etc...), but its cryptographic material can still be used to pin up an encrypted connection.

Scott Olsen Solutions Specialist Bulletproof Solutions Inc. Web: www.bulletproofsi.com
0 Helpful

buildingblockvideo
Level 1
Level 1
In response to Scott Olsen

‎02-23-2016 08:58 AM

I have tried adding the sid to the header of the curl commands and still have no control, below is a verbose output from curl, the first time i send the command the result is "Camera control request succeeded" although the camera does not move with any value in the pan, tilt or zoom section. The second time i send the command there is a 3 to 5 second hang before responding with "Camera controls for device '63062383-054e-4406-baee-71b27888d65e' failed [Serial passthrough failed for port:0 chainNo:1 - ].".
The token is obtained using the get token command with the above sid and works fine for the video connection.
I have even tried adding --header "x-ism-sid: ISMfbb1a96c-d460-42b4-88d8-08239a4eb770" which is the sid that is used to generate the token in the first place.
any other ideas?
ilt=0\&zoom=0\&priority=100\&token=63062383-054e-4406-baee-71b27888d65e^LVEAMPZOTD^50^0^0^1676908488^01dbf56e971127eeaa536b94
efe62466ba67b74d
* About to connect() to 192.168.1.197 port 443 (#0)
*   Trying 192.168.1.197...
* Adding handle: conn: 0x768c8
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x768c8) send_pipe: 1, recv_pipe: 0
* Connected to 192.168.1.197 (192.168.1.197) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS Unknown, Unknown (22):
* SSLv3, TLS handshake, Client hello (1):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Server hello (2):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, CERT (11):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Server finished (14):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv2, Unknown (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Finished (20):
* SSLv2, Unknown (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
*        subject: CN=localhost.localdomain
*        start date: 2015-04-08 12:48:01 GMT
*        expire date: 2017-04-07 12:48:01 GMT
*        issuer: CN=localhost.localdomain
*        SSL certificate verify result: self signed certificate (18), continuing anyway.
* SSLv2, Unknown (23):
* SSLv2, Unknown (23):
> GET /ums/ManagedDevices/CameraControls/63062383-054e-4406-baee-71b27888d65e/doPTZ?pan=1000&tilt=0&zoom=0&priority=100&token=63062383-054e-4406-baee-71b27888d65e^LVEAMPZOTD^50^0^0^1676908488^01dbf56e971127eeaa536b94efe62466ba67b74d HTTP/1.1
> User-Agent: curl/7.30.0
> Host: 192.168.1.197
> Accept: */*
>
* SSLv2, Unknown (23):
* SSLv2, Unknown (23):
< HTTP/1.1 200 OK
< Date: Tuesday, 23-Feb-16 10:38:29 GMT
* Server Cisco VSMS-Server is not blacklisted
< Server: Cisco VSMS-Server
< Expires: Tuesday, 23-Feb-16 10:38:29 GMT
< Pragma: no-cache
< Content-Type: application/xml
< Content-Length: 275
<
<?xml version="1.0" encoding="UTF-8"?>
<ResponseStatus>
   <requestURL></requestURL>
   <statusCode>0</statusCode>
   <statusString>Camera control request succeeded</statusString>
   <minorCode>2</minorCode>
   <minorStatusString>Updated</minorStatusString>
* Connection #0 to host 192.168.1.197 left intact
</ResponseStatus>~ #
ilt=0\&zoom=0\&priority=100\&token=63062383-054e-4406-baee-71b27888d65e^LVEAMPZOTD^50^0^0^1676908488^01dbf56e971127eeaa536b94
efe62466ba67b74d
* About to connect() to 192.168.1.197 port 443 (#0)
*   Trying 192.168.1.197...
* Adding handle: conn: 0x768c8
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x768c8) send_pipe: 1, recv_pipe: 0
* Connected to 192.168.1.197 (192.168.1.197) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS Unknown, Unknown (22):
* SSLv3, TLS handshake, Client hello (1):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Server hello (2):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, CERT (11):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Server finished (14):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv2, Unknown (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Finished (20):
* SSLv2, Unknown (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv2, Unknown (22):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
*        subject: CN=localhost.localdomain
*        start date: 2015-04-08 12:48:01 GMT
*        expire date: 2017-04-07 12:48:01 GMT
*        issuer: CN=localhost.localdomain
*        SSL certificate verify result: self signed certificate (18), continuing anyway.
* SSLv2, Unknown (23):
* SSLv2, Unknown (23):
> GET /ums/ManagedDevices/CameraControls/63062383-054e-4406-baee-71b27888d65e/doPTZ?pan=1000&tilt=0&zoom=0&priority=100&token=63062383-054e-4406-baee-71b27888d65e^LVEAMPZOTD^50^0^0^1676908488^01dbf56e971127eeaa536b94efe62466ba67b74d HTTP/1.1
> User-Agent: curl/7.30.0
> Host: 192.168.1.197
> Accept: */*
>
* SSLv2, Unknown (23):
* SSLv2, Unknown (23):
< HTTP/1.1 400 Bad Request
< Date: Tuesday, 23-Feb-16 10:40:41 GMT
* Server Cisco VSMS-Server is not blacklisted
< Server: Cisco VSMS-Server
< Expires: Tuesday, 23-Feb-16 10:40:41 GMT
< Pragma: no-cache
< Content-Type: application/xml
< Content-Length: 382
<
<?xml version="1.0" encoding="UTF-8"?>
<ResponseStatus>
   <requestURL></requestURL>
   <statusCode>3</statusCode>
   <statusString>Camera controls for device &apos;63062383-054e-4406-baee-71b27888d65e&apos; failed [Serial passthrough failed for port:0 chainNo:1 - ].</statusString>
   <minorCode>6</minorCode>
   <minorStatusString>Bad Request</minorStatusString>
* Connection #0 to host 192.168.1.197 left intact
</ResponseStatus>~ #
0 Helpful
Customers Also Viewed These Support Documents