How do you install an intermediate certificate on ISY?

[ahwman]

Hello,

 

I purchased an SSL certificate from Alpha SSL and was able to copy and paste the SSL certificate into my ISY994, however the directions state that I must also install an intermediate certificate and don't know how to do so.

 

Can anyone help?

Thanks!

[MWareman]

You will probably need to add the intermediate as a CA using the dashboard.

 

Normally, the intermediate needs to be returned with the signed public key during an SSL negotiation. I'm working on this myself - its likely that we need to put the root, intermediate and signed cert into one file and import that as the certificate bundle.

 

As I've mentioned, I have SSL on my Apache (Ubuntu) host and use that to proxy to my ISY. It might take a contact with support to find out the correct way to do this directly on the ISY, especially since they use AlphaSSL certs themselves on their Portal!

[ahwman]

You will probably need to add the intermediate as a CA using the dashboard.

Normally, the intermediate needs to be returned with the signed public key during an SSL negotiation. I'm working on this myself - its likely that we need to put the root, intermediate and signed cert into one file and import that as the certificate bundle.

As I've mentioned, I have SSL on my Apache (Ubuntu) host and use that to proxy to my ISY. It might take a contact with support to find out the correct way to do this directly on the ISY, especially since they use AlphaSSL certs themselves on their Portal!

Thanks for the reply,

 

I've tried as you suggest by combining the root, intermediate and signed cert into a text file, then copying and pasting it into the ISY which it accepts. However, I'm still getting an error when using the Maker channel in IFTTT "Action skipped - Unable to make web request: Error: unable to verify the first certificate".

 

Chuck

[MWareman]

This is what I've tried....

 

I created a .pem cert from the private key, certificate public key and the chain key with the following command:

openssl pkcs12 -export -out cert.new.pfx -inkey cert.key -in cert.pem -certfile chain.pem

I verified the pem bundle with the following command:

openssl pkcs12 -info -in cert.new.pfx

..and it definitely contains the cert public key, cert private key and the chain public key. All good.

 

I used the dashboard to import the pfx bundle...  it accepts it and ISY reboots.

 

I use Windows to browse UDAJAX over SSL - looks good.

 

I used openssl to test the installation:

openssl s_client -connect 192.168.1.20:5228

I got the following response:

CONNECTED(00000003)
depth=0 OU = Domain Control Validated, CN = *.domain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, CN = *.domain.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = Domain Control Validated, CN = *.domain.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.domain.com
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
Server certificate
-----BEGIN CERTIFICATE-----
<cert blob removed>
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=*.domain.com
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
No client certificate CA names sent
---
SSL handshake has read 1449 bytes and written 655 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
<SSL Session block removed>

Note the 'Certificate chain' block - it ONLY contains the one certificate...

 

This same certificate on my Apache host (properly installed) looks like this:

CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.domain.com
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
 1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
 2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
<certificate blob removed>
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=*.domain.com
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
No client certificate CA names sent
---
SSL handshake has read 4002 bytes and written 479 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
<SSL Session block removed>

Note that not only is the issued cert returned - but so is the intermediate AND root. This is what needs to happen for IFTTT to properly trust the endpoint.

 

I further used SSLLabs to test - it shows that the chain cert was NOT sent by ISY - so the chain is incomplete. You cannot use SSLLabs if your port is anything other than 443 - in this case you can try https://www.sslshopper.com/ssl-checker.html. It also shows a broken trust chain when the certificate is served from ISY.

 

At this point - it's a support call to UDI I'm afraid. ISY seems to be NOT sending the intermediate and root certificate - which is required for SSL to succeed to IFTTT.

 

Michael.

[ahwman]

This is what I've tried....

 

I created a .pem cert from the private key, certificate public key and the chain key with the following command:

 

openssl pkcs12 -export -out cert.new.pfx -inkey cert.key -in cert.pem -certfile chain.pem

I verified the pem bundle with the following command:

openssl pkcs12 -info -in cert.new.pfx

..and it definitely contains the cert public key, cert private key and the chain public key. All good.

 

I used the dashboard to import the pfx bundle...  it accepts it and ISY reboots.

 

I use Windows to browse UDAJAX over SSL - looks good.

 

I used openssl to test the installation:

openssl s_client -connect 192.168.1.20:5228

I got the following response:

CONNECTED(00000003)
depth=0 OU = Domain Control Validated, CN = *.domain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, CN = *.domain.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = Domain Control Validated, CN = *.domain.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.domain.com
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
Server certificate
-----BEGIN CERTIFICATE-----
<cert blob removed>
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=*.domain.com
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
No client certificate CA names sent
---
SSL handshake has read 1449 bytes and written 655 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
<SSL Session block removed>

Note the 'Certificate chain' block - it ONLY contains the one certificate...

 

This same certificate on my Apache host (properly installed) looks like this:

CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.domain.com
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
 1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
 2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
<certificate blob removed>
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=*.domain.com
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
No client certificate CA names sent
---
SSL handshake has read 4002 bytes and written 479 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
<SSL Session block removed>

Note that not only is the issued cert returned - but so is the intermediate AND root. This is what needs to happen for IFTTT to properly trust the endpoint.

 

I further used SSLLabs to test - it shows that the chain cert was NOT sent by ISY - so the chain is incomplete. You cannot use SSLLabs if your port is anything other than 443 - in this case you can try https://www.sslshopper.com/ssl-checker.html. It also shows a broken trust chain when the certificate is served from ISY.

 

At this point - it's a support call to UDI I'm afraid. ISY seems to be NOT sending the intermediate and root certificate - which is required for SSL to succeed to IFTTT.

 

Michael.

Thanks for all of your diligent efforts Michael. That said, this is somewhat new to me so I'm learning as I go. Where did you issue the commands to create the .pem file as the directions I followed suggest that you could simply paste each of the certs into one text file which I tried and renamed .pem but when I tried to import it using the Import Cert. it fails. So I ended up just pasting it using the Recieve Cert. button. Is the .pem creation done on your web server or a PC/Mac? Also, what option did you use to import it into the ISY?

 

Thanks,

I'll direct support to this link and hopefully we'll get a response...

[builderb]

If you have a Mac, use the Terminal app to issue those commands. On Windows you'll have to download something like CigWin. I don't think you can use Putty for this. Maybe PuttyKeygen? I do most of this on a Mac, myself.

 

I'd suggest running a web search on the commands before you do anything. Using PKI isn't too terribly complicated, but there's a real steep initial learning curve.

[MWareman]

I am using openssl on my Ubuntu host.

 

I also have a question in to Michel on the correct way to handle intermediate certificates.

 

Michael.

[ahwman]

If you have a Mac, use the Terminal app to issue those commands. On Windows you'll have to download something like CigWin. I don't think you can use Putty for this. Maybe PuttyKeygen? I do most of this on a Mac, myself.

I'd suggest running a web search on the commands before you do anything. Using PKI isn't too terribly complicated, but there's a real steep initial learning curve.

Thanks, I have a Mac and PC but at this point I think I'll just wait until we hear back from UDI on this issue...

[ahwman]

I am using openssl on my Ubuntu host.

 

I also have a question in to Michel on the correct way to handle intermediate certificates.

 

Michael.

I came across this post from Michel from UDI and unless something has changed since this post, it seems we have our answer for now. The link to this thread is located at: http://forum.universal-devices.com/topic/14033-importing-certificate/

 

"Hi Steven,

 

Unfortunately not. At the moment, intermediate certificates must be installed in the browser.

 

With kind regards,

Michel"

[MWareman]

Unfortunately, that's not how the TLS spec works. Intermediate certs must be returned by the server for the subordinate cert to be trusted at all.

 

As we all know, its not possible to install an intermediate on IFTTT.

[ahwman]

Unfortunately, that's not how the TLS spec works. Intermediate certs must be returned by the server for the subordinate cert to be trusted at all.

As we all know, its not possible to install an intermediate on IFTTT.

I got a confirmation email back from Michel that the ISY doesn't support intermediate certificates so we have our answer. That said, it looks like I wasted my money on an SSL certificate as I have no use for it outside of IFTTT/Maker channel. The only option I see is to use a proxy server as some are doing, however that just creates a whole new level of complication, so I guess I'll just have to wait until the ISY skill is released and hope that UDI will soon support IFTTT natively...

 

Chuck

[MWareman]

Unfortunately, by not handling an intermediate certificate, the ISY fails to adhere to the TLS standard RFC5426.  In particular:

 

http://tools.ietf.org/html/rfc5246#section-7.3

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

             Figure 1.  Message flow for a full handshake

and 

7.4.2.  Server Certificate

   When this message will be sent:

      The server MUST send a Certificate message whenever the agreed-
      upon key exchange method uses certificates for authentication
      (this includes all key exchange methods defined in this document
      except DH_anon).  This message will always immediately follow the
      ServerHello message.

   Meaning of this message:

      This message conveys the server's certificate chain to the client.

      The certificate MUST be appropriate for the negotiated cipher
      suite's key exchange algorithm and any negotiated extensions.
   Structure of this message:

      opaque ASN.1Cert<1..2^24-1>;

      struct {
          ASN.1Cert certificate_list<0..2^24-1>;
      } Certificate;

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

So, client connects and requests SSL

Server sends back a message containing a 'Certificate' to convey 'the server's certificate chain to the client.'

 

 

Please pay attention to the use of 'MUST' in the standard..

 

The certificates MUST be sent by the server to the client in sequence, with the senders certificate first, followed by the next certificate that verifies the device certificate and so on until a root. The server actually sends the root as well (as evidenced with the way Apache does it).

 

The signature of the root is able to be verified by the client - and so the entire chain is trusted.

 

Without the intermediate and root being sent by the ISY - a strict RFC browser can never trust the certificate. Why? Well - if the client cannot verify the certificate of the signing CA then the connection should be refused. Since the ISY cert was issued by the intermediary - but the client only has the root - the chain of trust is broken.

 

Michel: PLEASE add this!  It's terribly important - especially now that 90% of CAs (even big guys like Verisign) issue from subordinates. It fundamentally makes server side SSL impractical on the ISY without it - and it's a violation of the RFC to support TLS and not support the proper sending of the certificate chain.

 

The only reason I haven't hit this in the past is I've proxied access to my ISY. 

 

Michael.

[ahwman]

Unfortunately, by not handling an intermediate certificate, the ISY fails to adhere to the TLS standard RFC5426. In particular:

 

http://tools.ietf.org/html/rfc5246#section-7.3

 

Client                                               Server      ClientHello                  -------->                                                      ServerHello                                                     Certificate*                                               ServerKeyExchange*                                              CertificateRequest*                                   <--------      ServerHelloDone      Certificate*      ClientKeyExchange      CertificateVerify*      [ChangeCipherSpec]      Finished                     -------->                                               [ChangeCipherSpec]                                   <--------             Finished      Application Data             <------->     Application Data             Figure 1.  Message flow for a full handshake

and

7.4.2.  Server Certificate   When this message will be sent:      The server MUST send a Certificate message whenever the agreed-      upon key exchange method uses certificates for authentication      (this includes all key exchange methods defined in this document      except DH_anon).  This message will always immediately follow the      ServerHello message.   Meaning of this message:      This message conveys the server's certificate chain to the client.      The certificate MUST be appropriate for the negotiated cipher      suite's key exchange algorithm and any negotiated extensions.   Structure of this message:      opaque ASN.1Cert<1..2^24-1>;      struct {          ASN.1Cert certificate_list<0..2^24-1>;      } Certificate;   certificate_list      This is a sequence (chain) of certificates.  The sender's      certificate MUST come first in the list.  Each following      certificate MUST directly certify the one preceding it.  Because      certificate validation requires that root keys be distributed      independently, the self-signed certificate that specifies the root      certificate authority MAY be omitted from the chain, under the      assumption that the remote end must already possess it in order to      validate it in any case.

So, client connects and requests SSL

Server sends back a message containing a 'Certificate' to convey 'the server's certificate chain to the client.'

 

 

Please pay attention to the use of 'MUST' in the standard..

 

The certificates MUST be sent by the server to the client in sequence, with the senders certificate first, followed by the next certificate that verifies the device certificate and so on until a root. The server actually sends the root as well (as evidenced with the way Apache does it).

 

The signature of the root is able to be verified by the client - and so the entire chain is trusted.

 

Without the intermediate and root being sent by the ISY - a strict RFC browser can never trust the certificate. Why? Well - if the client cannot verify the certificate of the signing CA then the connection should be refused. Since the ISY cert was issued by the intermediary - but the client only has the root - the chain of trust is broken.

 

Michel: PLEASE add this! It's terribly important - especially now that 90% of CAs (even big guys like Verisign) issue from subordinates. It fundamentally makes server side SSL impractical on the ISY without it - and it's a violation of the RFC to support TLS and not support the proper sending of the certificate chain.

 

The only reason I haven't hit this in the past is I've proxied access to my ISY.

 

Michael.

Michel has suggested to me to purchase a certificate which doesn't use intermediaries. Do you think this would work as a temporary work around with IFTTT/Maker channel until UDI supports the correct implementation? If so, where does one buy such a certificate?

 

Chuck

[Michel Kohanim]

MWareman,

 

The specs talk about certificates that have intermediaries (as a list). ISY does not support intermediaries and that was on purpose for specific trust issues arising in high security communications with only the root. We might have to put a flag in there and exclude it from high security and include it in other cases. At the moment, however, it has very low priority.

 

With kind regards,

Michel

[MWareman]

 

 

MWareman,

 

The specs talk about certificates that have intermediaries (as a list). ISY does not support intermediaries and that was on purpose for specific trust issues arising in high security communications with only the root. We might have to put a flag in there and exclude it from high security and include it in other cases. At the moment, however, it has very low priority.

 

With kind regards,

Michel

I'd be interested to hear more about the reason for choosing to exclude support for intermediaries. In the TLS world, not supporting it actually prevents the ISY from being able to be verified by a strict RFC compliant client, such as IFTTT, when a chained certificate is in use. It seems a counter-intuitive choice to make.

 

UDIs own Portal (https://my.isy.io) uses a RapidSSL certificate, where RapidSSL is the intermediate to a Geotrust root. The portal correctly handles the TLS connection. Why support it there yet not on the ISY?

 

As asked above, this would be a non-issue if retail certificates were available without intermediate certs. That's not been the case now for at least a couple of years - but the ISY manual continues to advise customers to purchase a certificate to use with the ISY, and the result is that the certificate cannot be verified by remote API's.

 

This is not only the case with IFTTT. All APIs I've played with verify the full trust, and this failed when the server does not send the full chain.

 

Do you have a suggestion where, at retail, certificates can be purchased with a single root for use in the ISY?

[Michel Kohanim]

MWareman,

 

As I mentioned before, we had a high security requirement for which intermediaries were not allowed. With regards to your question:

1. Intermediaries can be installed in the clients (browsers)

2. For API calls, we will have to implement intermediaries

 

Again, priority is low.

 

With kind regards,

Michel

[MWareman]

MWareman,

 

As I mentioned before, we had a high security requirement for which intermediaries were not allowed. With regards to your question:

1. Intermediaries can be installed in the clients (browsers)

2. For API calls, we will have to implement intermediaries

 

Again, priority is low.

 

With kind regards,

Michel

OK sounds good.

 

I can see how having the option to reject intermediaries would assist in certain scenarios - specifically in the role of a client. But in the role of a server, it provides zero benefit.

 

I understand that the decision was probably a while ago, but in the role of a server not allowing intermediaries as an option actually makes the product non-compliant with the TLS 1.2 specification.

 

As a work around, do you have a source for single-root retail certificates at a price point somewhat friendly to non enterprise users?

 

Michael.

 

Edit. Saw this post: http://forum.universal-devices.com/index.php?/topic/17212-ISY-Portal-Says-Device-Offline&do=findComment&comment=155291

What is the reason 'Verify' needs to be unchecked? Is it because ISYPortal uses a chained certificate, but ISY cannot verify a chain in the client role either?

 

Leaving 'Verify' unchecked leaves the connection open to man in the middle attack scenarios. It would definitely make the case for making this a higher priority then 'Low' - personally I would place this in the category of 'vulnerability'.

 

Either that - or you should get a single root cert for my.isy.io so we don't have to unchecked 'Verify' for the portal to work.

[Michel Kohanim]

Hi MWareman,

 

I agree that as the server we would have to support intermediaries eventually. I do have a source (OpenADR Alliance) for servers but a) the price is high and in all likelihood the server will not like it. We can certainly test a test certificate and see if the server likes it. If you are up for it, please send me an email and I'll send one to you.

 

With kind regards,

Michel

[MWareman]

I don't really think high priced certs are feasible for most people - so I'm not sure the value testing this option. Thanks for the offer anyway!

 

I did just edit the post above referencing another post. Can you confirm why 'Verify' needs to be unchecked in the TLS client to work with ISYPortal?

 

Thanks!

 

Michael.

[Michel Kohanim]

Hi MWareman,

 

Agreed. The reason is that Verify is for client authentication and it's GLOBAL. So, if you check that option (and include the intermediaries in the CA list), then all other https connections will try to authenticate the server (such as gmail, etc.) and will fail.

 

This is part of the enhanced security that we are working on: making client authentication connection based and not global.

 

With kind regards,

Michel

[MWareman]

So, with the global client side 'Verify' checked, all connections to servers that have a chained certificate will fail because ISY doesn't process the chain at all - client or server side. The user would have to import the root AND intermediate certs for all services they need to connect to if they needed 'Verify' checked.

 

How do customers using their ISY for power integration also use the portal, if global 'verify' must be unchecked for the ISYPortal to work, but I suspect this would violate policy for OpenADR?

 

How will processing change with connection based policies? Will this include the processing of a chain?

 

As I mentioned, by needing 'Verify' to be unchecked it leaves open a vulnerability, as any self-signed cert with the common name 'my.isy.io' on a proxy, and a DNS cache poisoning attack can be combined to compromise the encrypted communications between the ISY and the ISYPortal. I feel that on its own justifies higher than a 'low' priority fix.

 

Michael.

[Michel Kohanim]

No,

 

Chained certificates will work if and only if the CAs are installed in ISY.

 

With kind regards,

Michel

[MWareman]

No,

 

Chained certificates will work if and only if the CAs are installed in ISY.

 

With kind regards,

Michel

OK, thanks. So this is another deviation from the requirements of TLS 1.2. Normally, only the root need be installed. It's up to the server to send its own cert and any needed intermediaries ultimately chaining to a root that's in the ISY.

 

By not implementing this (required) ability, we have to manage not only the roots, but also the intermediaries directly in the ISY. Given that intermediaries change fairly often with most CAs, this is entirely impractical.

 

That being said, asking people to deselect 'verify' to work around this creates a vulnerability - and this alone should cause the issue to raise above 'low' priority.

 

Would it not be better to advise people to simply import the Globalsign root and RapidSSL intermediate root into their ISY with the Dashboard and leave 'verify' checked? (Especially if they've previously been successfully using the ISY with 'verify' checked in the client).

 

Michael.

[Michel Kohanim]

No. As I mentioned before, this is a global setting and will impact everything else.

 

Point taken, still low priority.

 

With kind regards,

Michel

[MWareman]

No. As I mentioned before, this is a global setting and will impact everything else.

 

Point taken, still low priority.

 

With kind regards,

Michel

OK, thanks. I'll be content that it's on the list - even if fairly low.

 

To others: the best way around this is to run a Raspberry PI. Either with Apache/PHP or one of the various Python solutions on here you can create an inbound proxy to the REST API that the Maker IFTTT channel can call. I'm using PHP and have posted my script above. You can use any paid certificate on the rpi as long as its installed correctly.