SSL Certificate format

[jch]

What is the format of the SSL Certificate that the ISY expects (in 2.7.10)?

 

I have generated a certificate from CACERT and would like to use that in my ISY.

 

Thanks.

 

Jeff

[Michel Kohanim]

Hi Jeff,

 

The format is ISY specific. It uses X501 certificates but decomposed into p, q, exp, mod, with their lengths.

 

We are planning to support CA certified formats in the future but have assigned it a very low priority since most people are not willing to pay between $14.00 to $400.00 per year for a certificate.

 

With kind regards,

Michel

What is the format of the SSL Certificate that the ISY expects (in 2.7.10)?

 

I have generated a certificate from CACERT and would like to use that in my ISY.

 

Thanks.

 

Jeff

[jch]

CACert.org certificates are free. I believe there are also authorities that provide free certificates.

 

The advantage to a CACert.org certificate is that I have already added their root certificates to all my browsers, so no need to repeat the effort for every host.

 

Is it only a matter of reformatting the data to be able to use the different format?

 

Thanks.

 

Jeff

[Michel Kohanim]

Hi Jeff,

 

Would you be kind enough to send an email with this information to tech@universal-devices.com . I will see what we can do to support them.

 

No, it's not as easy as formatting ... everything in the certificate is binary.

 

With kind regards,

Michel

[markens]

In addition to the free CAs mentioned, it's trivial to generate (free) self-signed X501 certificates. These can also be "introduced" to browsers for secure connections. I do this for my personal domain (web server and clients).

 

Michel, I'm not sure what the problem is here. If a certificate is supplied in standard X501 format, why can't the ISY simply store it and pass it on to the client during the SSL conversation? If there isn't enough horsepower in the ISY to do this directly due to ISY format issues, then perhaps a conversion/installation utility based on openssl could be used.

 

--Mark

[Michel Kohanim]

Hi Mark,

 

I am not sure what you are referring to since that's precisely what our utility does: it generates self signed certificates in X501 format and then submits it to ISY. Haven't you already tried this?

 

With kind regards,

Michel

[markens]

I am not sure what you are referring to since that's precisely what our utility does: it generates self signed certificates in X501 format and then submits it to ISY. Haven't you already tried this?

Yes, I had no problem using your utility. The cert generated this way is what I currently have installed in my ISY. And I think it's great that you provide such a convenient utility to take care of this chore, handling 95% of the needs of UDI customers. Again, far beyond what most suppliers do!

 

But the point in this thread is that your utility self-signs a certificate that it generates, using its own CA information (which cannot be changed via your utility). I'm talking about installing a certificate that I generate externally, using my own CA, and that I sign. I think that's what Jeff is talking about, too (at least, generated and signed by a CA external to UDI/ISY).

 

Does your utility use openssl tools to generate its self-signed certificate? If so, it should be very straightforward to extend to allow installation of user-supplied X501 certs.

 

Not a huge issue for me, but I wanted to chime in on the subject to help clarify the request.

 

--Mark

[Michel Kohanim]

Hi Mark,

 

Thanks so very much for the clarification.

 

I totally agree ... there are NO problems whatsoever in supporting other CA certified certificates (except spending time and resources). All we have to do is to extract the p, q, mod, and exp out of the certificate.

 

This is on our list and shall eventually be done. I just cannot commit to a date.

 

With kind regards,

Michel

[markens]

This is on our list and shall eventually be done. I just cannot commit to a date.

Thanks, Michel!

 

--Mark

[Michel Kohanim]

Hello all,

 

I just wanted to let you know that we have implemented CA certificates and need your help with testing. Our test with CACert.org worked perfectly but have not gone beyond that.

 

To test:

1. Please go to https://www.universal-devices.com/ssl/insteon

2. Login

3. From the menu, choose Generate Certificate Request to CA

4. Copy the contents in 3 to the clipboard and send it to your CA

5. Once you have your CA signed certificate:

a. Copy the certificate to clipboard

b. Go to Receive Certificate from CA and Install

c. Click on Paste from Clipboard

d. Click on OK ...

e. IMPORTANT: When prompted to save the certificate - and if you so choose - save your certificate in a safe place

 

 

Looking forward to your feedback.

 

With kind regards,

Michel

[mitch236]

Since I've never been able to get a certificate to work, I don't see why they are necessary. Am I missing something? Also, I must be doing something wrong with certificates as I always get the warning when accessing the ISY through the internet, even on my office computer despite me installing a self generated certificate!

 

Thanks

[markens]

I just wanted to let you know that we have implemented CA certificates and need your help with testing. Our test with CACert.org worked perfectly but have not gone beyond that.

That was fast! I'll take a look later today or tomorrow and post comments.

 

Since I've never been able to get a certificate to work, I don't see why they are necessary. Am I missing something? Also, I must be doing something wrong with certificates as I always get the warning when accessing the ISY through the internet, even on my office computer despite me installing a self generated certificate!

 

In many respects, ssl certificates are black magic. Especially when attempting to use them for more than their most basic capabilities. No disrespect, but just because you don't see why they're necessary does not make them useless!

 

As for the warnings, you don't say specifically what warning you're getting. I suspect it's one of two, though: (1) cert signed by non-trusted source, or (2) the common name in the cert does not match the site address you used to connect to the site.

 

The following explanation might get a bit technical, but I hope it's useful:

 

A self-signed cert will always generate warning (1), unless you have installed a CA cert (generated separately from the CA signing your cert) telling the browser that you trust it and all certs signed by it. Or, you can also "accept" the self-signed cert directly into the browser as permanently trusted, in which case you shouldn't be warned about it again.

 

Reason (2) is also very common. This means that the cert is issued to CN (common name, or site name) xxx.yyy.com, but the URL you use in your browser to actually connect to the page is something different. This mismatch is generally considered a bad thing (one site trying to masquerade as another), which is why the warning is issued. Some browsers will let you override this warning as well, while others won't.

 

--Mark

[markens]

Michel,

 

Several quick comments:

 

(1) The UI of the SSL config utility includes empty ISY tabs (Main/Program Summary/Program Details/Configuration). I don't remember these from before. Should they be there?

 

(2) "Install Existing SSL Certificate" menu choice -- is this the method to reinstall a self-signed cert previously generated (and saved) by this utility? If so, are versions compatible between firmware updates?

 

(3) Before trying the new CA functions, I simply tried to generate and install a new self-signed cert. This failed. I had a perfectly good cert in my ISY which worked before this process, and after the reboot it looks like port 443 is not available ("no connection" error from client).

 

Help please! How do I get back to a working ISY self-signed cert? I'm running 2.7.7 firmware if that matters. (And if it does matter, why doesn't the config utility check for this and refuse to function if there is a version mismatch?)

 

Thanks,

--Mark

[markens]

Michel,

 

Couple more things:

 

- You may want to look at the appropriateness of the "Publisher Name" chosen for the Java certificate used for signing your SSL classes. "The Legion of the Bouncy Castle" doesn't really give me much confidence. If the code path did not include "com.universal-devices" I would not have accepted it!

 

- I tried running the SSL config utility directly from my 2.7.7 admin menu. Looks like I got the same SSL utility, with the same "non-working" SSL port after installation of the self-signed cert.

 

--Mark

[markens]

Michel,

 

I've gone through the new cert signing process and have lots of comments. Bottom line is that the cert stuff appears to be ok, but the utility is not installing any cert to my ISY (self-signed or CA-signed).

 

First: please verify that this process should work with 2.7.7 firmware. If not, that probably explains the problems I'm having!

 

Here's what I'm seeing:

 

- touch and go at first. SSL utility appeared to crash the first time I tried to import a received cert ("Information" popup was blank and nothing further happened; closed and restarted, got "Can't find private key" error. Started over.)

 

Here are results of my last runthrough, which was clean until the end:

 

- The CERTIFICATE REQUEST generated by your utility appears fine with the CA. But why is the following attribute included in the request, especially the email address?

 

Requested Extensions:

X509v3 Subject Alternative Name:

email:ncp.edu.pk

 

The CA ignored it, but I still wonder why it's included in the request.

 

- CA signed the request ok, and returned the signed cert, in the following text format:

 

-----BEGIN CERTIFICATE-----

[. . . . .]

-----END CERTIFICATE-----

 

This is what I pasted into the ISY utility to receive the certificate. Is this what you're expecting? (Specifically, you're expecting a pem-encoded CERTIFICATE rather than a p12-format certificate intended for a browser. Right?)

 

- The utility appeared to accept it, although the UD.DCF save file was not written to my local computer. ISY rebooted. http access fine, but still no response on port 443.

 

I'd be happy to send you privately the actual cert request and signed cert if you would like to see them.

 

What now? At the very least, I'd like to get a self-signed cert installed again so I can access the ISY via https!

 

Thanks,

 

--Mark

[mitch236]

[in many respects, ssl certificates are black magic. Especially when attempting to use them for more than their most basic capabilities. No disrespect, but just because you don't see why they're necessary does not make them useless!

 

As for the warnings, you don't say specifically what warning you're getting. I suspect it's one of two, though: (1) cert signed by non-trusted source, or (2) the common name in the cert does not match the site address you used to connect to the site.

 

The following explanation might get a bit technical, but I hope it's useful:

 

A self-signed cert will always generate warning (1), unless you have installed a CA cert (generated separately from the CA signing your cert) telling the browser that you trust it and all certs signed by it. Or, you can also "accept" the self-signed cert directly into the browser as permanently trusted, in which case you shouldn't be warned about it again.

 

Reason (2) is also very common. This means that the cert is issued to CN (common name, or site name) xxx.yyy.com, but the URL you use in your browser to actually connect to the page is something different. This mismatch is generally considered a bad thing (one site trying to masquerade as another), which is why the warning is issued. Some browsers will let you override this warning as well, while others won't.

 

--Mark

 

I am using the self signed certificate so maybe that's why I get the warning. As for the specific warning, I'm not at my office now but it doesn't stop me from accessing the site, it just warns that the certificate may not be trustable. I also use TZO.com to forward my self assigned ip address to my non-static ip address so maybe I will never be able to rid myself of the warning. I don't mind it though.

 

I still don't understand why I need a certificate?

[markens]

I still don't understand why I need a certificate?

Brief answer:

 

All web servers that communicate via SSL (https) must have a security certificate available which is used as part of the secure communication with the client. The certificate is usually cryptographically "signed" by a trusted Certificate Authority according to stated authentication policies. All modern browsers come with a set of "root" CA certificates that are, by definition, trusted to sign server certificates. This can happen either directly (CA signs a server cert), or via a chain of trust. The browser warns you if there is any break in that chain of trust, from the installed root certificates all the way down to the particular server certificate for the current https page being loaded.

 

This is how the client knows that the server is who he says he is (for example, you're talking to the actual web server for your bank). And it's why the browser warns you of any anomalies in the chain of trust, or other problems with verification of the certificate.

 

Note that in all cases (whether you trust the certificate or not), the underlying web traffic is encrypted with a key unique to that session, known only to your client and the server. So nobody else can see the clear text traffic regardless of whether you trust that server or not. This is why a self-signed certificate is useful (since you would presumably trust this self-signed cert that you know you generated).

 

Enter the ISY: It could use a generic, default certificate. But you would have no idea whether you're talking to your ISY or someone else's ISY. By running the utility to install a unique cert in your ISY, you now know for sure (once you accept and install that cert in your browser) that you're talking to the same one every time.

 

This is just the basics. SSL certs can be used in increasingly complex mutual authentication schemes. For example, a company could issue client certs signed by its own corporate CA. Installed in a browser or other client, now the server can know that the client is authorized to receive services. And it goes on from there...

 

--Mark

[markens]

I also use TZO.com to forward my self assigned ip address to my non-static ip address so maybe I will never be able to rid myself of the warning. I don't mind it though.

I meant to ask you to clarify this: I would assume that you gave yourself a domain-based name at TZO.com (something like somename.tzo.com), not a numeric ip address. Is this the case? If so, then this is the name you should enter into the ISY SSL utility when generating a self-signed cert. Then, when you use that https://somename.tzo.com (or whatever) URL in your browser to access the ISY via this mechanism, you should not get a "hostname mismatch" warning.

 

--Mark

[Michel Kohanim]

Mark,

 

Thanks so very much for testing and apologies for killing your HTTPS.

 

The problem is that we had to change the format of our certificate so, you will have to have 2.7.10 or 2.7.11 (if you are on any other beta) for this to work. Once you upgrade to 2.7.11, everything will work fine.

 

1. The alternate name has been removed

2. Regions of Bouncy Castle - unlike their name - is the most widely used encryption library out there. We use it as is

3. Yes, we expect PEM formatted signed certificate

 

Thanks again and with kind regards,

Michel

[markens]

Michel,

 

The problem is that we had to change the format of our certificate so, you will have to have 2.7.10 or 2.7.11 (if you are on any other beta) for this to work. Once you upgrade to 2.7.11, everything will work fine.

That's what I thought -- thanks for the confirmation.

 

However: Since the menu item from within my 2.7.7 admin console took me to that same new SSL utility, does this mean that it's broken for everybody who is running less than 2.7.10? I'm not quite ready to upgrade to 2.7.11, so is there a URL to access the old SSL utility that will work in 2.7.7?

 

1. The alternate name has been removed

2. Regions of Bouncy Castle - unlike their name - is the most widely used encryption library out there. We use it as is

3. Yes, we expect PEM formatted signed certificate

 

1. Thanks!

2. Didn't know that. My crypto experience is more on the SSL side than java -- should have used the google before making the comment!

3. Good, thanks.

 

--Mark

[Michel Kohanim]

Hi Mark,

 

I am so terribly sorry ..

 

This utility should work fine on 2.7.7> version >= 2.7.10. So, 2.7.7, 8, and 9 (alpha) will not work.

 

I can surely get the library back from CVS and make a special URL for you. Or, if you have an old UD.DCF (if you saved it) you can use the last menu option to reinstall it.

 

With kind regards,

Michel

[markens]

Michel,

 

Success. I extracted the UD.DCF file from my latest ISY backup and reinstalled it using the utility. All works as before. Thanks, as always!

 

--Mark

[mitch236]

sorry for all my questions. If I have a SSL certificate, could I set it up so that only trusted computers could access my ISY?

 

On another note, when I request a certificate from CA, I get an error stating Not Implemented Yet. I running 2.7.10

 

Thanks!

[markens]

sorry for all my questions. If I have a SSL certificate, could I set it up so that only trusted computers could access my ISY?

This would require client certificates (which allow clients to be authenticated to the server). Michel should confirm, but it's very unlikely that the ISY performs client SSL authentication. So the answer to your question is no; username/password is still required to authenticate computers trying to access the ISY.

 

(The server certificate installed in the ISY allows the ISY to be authenticated to the client, the other direction. It also enables encrypted communications so eavesdroppers cannot see your data, including the username/password.)

 

On another note, when I request a certificate from CA, I get an error stating Not Implemented Yet. I running 2.7.10

Again, Michel should comment on the error received. But this is an advanced function that you probably are not set up for. Are you prepared to send the ISY's Certificate Signing Request to your Certificate Authority to be signed? If the answer is no (or you don't know what this means), then you should stick with ISY self-signed certificates and avoid using any of the "CA" options.

 

--Mark

[markens]

Michel,

 

I thought about this process a bit more, and have several more questions I'm hoping you can clarify since I can't test on my 2.7.7 ISY:

 

- When selecting the Generate Certificate Request to CA option, is the current SSL operation of the ISY affected at that point? I.e., will a currently installed self-signed cert continue to work? (Say a CSR is generated and a resulting signed cert is never "received" into the ISY.) Specifically, does the private key generated at this point overwrite the existing private key components in the ISY, rendering the previous certificate unusable?

 

- If the ISY is affected, then presumably the old cert file could be restored, or a new self-signed cert be installed.

 

- Does Generate Certificate Request to CA generate a new private key every time this is selected? (So every generated CSR has a new private key associated with it?)

 

Thanks,

 

--Mark