Error in adding Redfish supported Cisco IMC server in Manageiq

Hello,

I am trying to add a Cisco IMC server to manageiq physical infrastructure provider(Compute --> Physical Infrastructure --> Providers)

Type: Redfish.

When trying add, getting below error.
Credential validation was not successful: Unexpected response returned from system: SSL_connect returned=1 errno=0 state=error: certificate verify failed (self signed certificate) (OpenSSL::SSL::SSLError) Unable to verify certificate. This may be an issue with the remote host or with Excon. Excon has certificates bundled, but these can be customized: Excon.defaults[:ssl_ca_path] = path_to_certs ENV['SSL_CERT_DIR'] = path_to_certs Excon.defaults[:ssl_ca_file] = path_to_file ENV['SSL_CERT_FILE'] = path_to_file Excon.defaults[:ssl_verify_callback] = callback (see OpenSSL::SSL::SSLContext#verify_callback) or: Excon.defaults[:ssl_verify_peer] = false (less secure).

Certificate we using are self signed.

We have the uploaded certificate to CIMC : myserver05.crt

How to add a redfish server with self signed certificate to manageiq?

Thanks,
Mohan

I assume this is still the same issue as Unable to add a Cisco UCS server with a self signed certificate?

Hi buc

Apologies for posting again. I thought clarity was missing in previous post, didnt know the edit option at the end of the post.

Thanks,
Mohan

Hello Mohan,

when you add a Provider, in the Endpoints section you can select the Security Protocol as SSL without validation. Have you perhaps tried using that option?

Hi Matejart,

I am getting below error on selecting the security protocol as SSL without validation

Security Protocol : SSL without validation
Hostname (or IPv4 or IPv6 address) : 192.168.1.34
API Port : 443
Username: admin
password:admin

Credential validation was not successful: Unexpected response returned from system: Invalid credentials

When used curl call, we are getting response from the server

curl --insecure -u admin:admin https://192.168.1.34/redfish/v1/Systems

{
“Members”:[{
@odata.id”:"/redfish/v1/Systems/sys-id"
}],
“Description”:“Collection of Computer Systems”,
@odata.type”:"#Cisco_ComputerSystemCollection",
@odata.id”:"/redfish/v1/Systems",
“Members@odata.count”:1,
“Name”:“Computer System Collection”,
@odata.context”:"/redfish/v1/$metadata#Systems"
}

Thanks,
Mohan

Hello Mohan,

does your Redfish server support session logins? If you run:

curl -k -L  https://192.168.1.34/redfish/v1

there should be a Links.Sessions["@odata.id"] as the next URL to use, e.g.:

{
  [ ... ]
  "Links": {
    "Sessions": {
      "@odata.id": "/redfish/v1/SessionService/Sessions"
    }
  },
  [ ... ]
}

Use this URL to try and log into a session, e.g.:

curl -v -k -L \
    -d '{"UserName":"admin","Password":"admin"}' \
    -H "Content-Type: application/json" \
    https://192.168.1.34/redfish/v1/SessionService/Sessions

What is the outcome of this command?

[ edited to add ]
What you should be getting is a JSON document that looks like this:

> POST /redfish/v1/SessionService/Sessions HTTP/1.1
[ ... ]
< Content-Type: application/json
< X-Auth-Token: UUID-USED-AS-SESSION-TOKEN
[ ... ]
{
  "@odata.id": "/redfish/v1/SessionService/Sessions/UUID-USED-AS-SESSION-TOKEN",
  "Id": "UUID-USED-AS-SESSION-TOKEN",
  "Name": "UUID-USED-AS-SESSION-TOKEN",
  "@odata.type": "#Session.v1_1_0.Session",
  "UserName": "redfish",
  "Password": null
}

Hi matejat

curl -v -k -L -d ‘{“UserName”:“admin”,“Password”:“admin”}’ -H “Content-Type: application/json” https://192.168.1.34/redfish/v1/SessionService/Sessions

  • Trying 192.168.1.34:443…
  • TCP_NODELAY set
  • Connected to 192.168.1.34 (192.168.1.34) port 443 (#0)
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /home/lenonvapc/anaconda3/ssl/cacert.pem
    CApath: none
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  • TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • TLSv1.2 (IN), TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / AES256-GCM-SHA384
  • ALPN, server did not agree to a protocol
  • Server certificate:
  • subject: C=US; ST=California; L=San Jose; O=Cisco Systems Inc; CN=C220-NGHTY
  • start date: Nov 4 10:11:53 2019 GMT
  • expire date: Nov 3 10:11:53 2020 GMT
  • issuer: C=US; ST=California; L=San Jose; O=Cisco Systems Inc; CN=C220-NGHTY
  • SSL certificate verify result: self signed certificate (18), continuing anyway.

POST /redfish/v1/SessionService/Sessions HTTP/1.1
Host: 192.168.1.34
User-Agent: curl/7.65.3
Accept: /
Content-Type: application/json
Content-Length: 44

  • upload completely sent off: 44 out of 44 bytes
  • Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    < Server: Monkey
    < Date: Sun, 17 Nov 2019 16:51:05 GMT
    < Transfer-Encoding: Chunked
    < X-Auth-Token: a71a57ad5a4413477d544dd577a57387
    < Status: 201
    < Content-Type: application/json
    < Content-Length:140
    <
    {
    @odata.id”:"/redfish/v1/SessionService/Sessions/98",
    “Description”:“Session of user: admin”,
    “Name”:“User Session #98”,
    “Id”:98
    }
  • Connection #0 to host 192.168.1.34 left intact

Thanks,
Mohan

Thank you, Mohan!

The problem is that Cisco isn’t adhering to standards: the Redfish client expects the response code to be HTTP 201 . From your posted output I can see that Cisco IMC server instead returns status HTTP 200 . Having an additional non-standard response header Status: 201 won’t work.

I suggest to file this as a bug at Cisco.

Best regards,
Matej