koolandrew Posted February 10, 2016 Report Share Posted February 10, 2016 Hello, We recently purchased a 2048bit PositiveSSL Wildcard Certificate from Comodo and would like to install it over the Vodia Networks Inc. default certificate. Comodo sent us the following files: Root CA Certificate - AddTrustExternalCARoot.crtIntermediate CA Certificate - COMODORSAAddTrustCA.crt Intermediate CA Certificate - COMODORSADomainValidationSecureServerCA.crt Your PositiveSSL Wildcard Certificate - STAR_domain_com.crt Needless to say we also own the private key. Our goal is to remove the default Vodia Networks Inc certificate (Screenshot attached). Following the Vodia Wiki we went to Setting --> Certificates on the PBX we were able to add all the certificates mentioned above as “Trusted Root CA for server authentication”. However, we were not able to add our wildcard certificate in combination with our private key as either “Domain certificate chain + Private key” or “Server certificate chain + Private key”. This is what we tried: 1.) (As domain certificate chain + private key) 1.1) Wildcard certificate + Private key 1.2) Concatenated all certificates adding empty line between certificates + Private key 2.) (As server certificate chain + private key) 2.1) Wildcard certificate + Private key 2.2) Concatenated all certificates adding empty line between certificates + Private key 3.) (As domain certificate chain + private key) (Changed -----BEGIN PRIVATE KEY----- to -----BEGIN RSA PRIVATE KEY----- and -----END PRIVATE KEY----- to -----END RSA PRIVATE KEY----- ) 3.1) Wildcard certificate + Private key 3.2) Concatenated all certificates adding empty line between certificates + Private key 4.) (As server certificate chain + private key) (Changed -----BEGIN PRIVATE KEY----- to -----BEGIN RSA PRIVATE KEY----- and -----END PRIVATE KEY----- to -----END RSA PRIVATE KEY----- )) 4.1) Wildcard certificate + Private key 4.2) Concatenated all certificates adding empty line between certificates + Private key For any combination above, once we click “Save” simply nothing happens. We would be very grateful if someone could help us replace the default Vodia Networks Inc certificate with our own so we can start using https without getting “This connection is untrusted“ messages in the browser. Thank you in advance! Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 10, 2016 Report Share Posted February 10, 2016 Everything needs to be base64-encoded. Use a text editor to make sure that you can see it. If you are using SHA2 certificates, make sure that you are using 5.2.6 or later. First comes the certificate it self, and then the intermediate certs in the cert input field. The private key goes into the input field for the private key. It must not have a password (this is not supported, as it would require you to enter the password when you start the PBX up). If it all does not help, we can import it for you. Quote Link to comment Share on other sites More sharing options...
koolandrew Posted February 10, 2016 Author Report Share Posted February 10, 2016 Thanks for the quick reply, we will try your suggestions and report back! Quote Link to comment Share on other sites More sharing options...
koolandrew Posted February 11, 2016 Author Report Share Posted February 11, 2016 Following your post we went and tried again.All our certificates are base64 encoded and visible in a text editor. We are using the same certificates for other services as well. Our private key has no password. We are using a version later than 5.2.6.As you mentioned, we put our wildcard certificate into the certificate field first, followed by our intermediate certificate. We tried both intermediate certificates at a time as we were given two (COMODORSADomainValidationSecureServerCA.crt, COMODORSAAddTrustCA.crt). In both cases we tried concatenating our wildcard certificate with one of the intermediate certificates with and without leaving a blank line in between.We also tried adding the private key as:-----BEGIN PRIVATE KEY-----and-----END PRIVATE KEY-----as well as:-----BEGIN RSA PRIVATE KEY-----and-----END RSA PRIVATE KEY-----Neither of the above combinations worked either in "Domain certificate chain + private key" or "Server certificate chain + private key" mode. I've spent hours trying to get this to work meticulously entering every possible combination there is.Is there a log in the PBX that shows what the problem might be? Possibly a debug log that can be enabled?We are very thankful for you getting back but don't know what else to try to get this to work. Unless we get more detailed instructions we believe this simply can't be done.Please understand that we can't let a 3rd party handle our key and certificates as it would compromise our whole PKI. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 11, 2016 Report Share Posted February 11, 2016 Maybe you can send us a private message with the certificates and the general structure of the private key (without the actual private key), so that we can try this out here in the debugger. Quote Link to comment Share on other sites More sharing options...
koolandrew Posted February 11, 2016 Author Report Share Posted February 11, 2016 I dont want to be sending any part of our certs through email or message. 1. Why do you have the snom/vodia certifcates, as they are tied to localhost, which as you aware, are pretty well useless. Is there any way to add the credentials of the domain to this cert so we can use it. 2. Is this even possible. Every time we have tried, we get no response. Where are the logs located that would help us trouble shoot this issue. If it cant be done, it cant be done. Just let me know. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 11, 2016 Report Share Posted February 11, 2016 No, it can be done. We helped some fold with wildcard certificates already long time ago. It is a hassle, but it works (should work). Try to turn TLS logging on to level 9 when you import the certificate. Maybe you can get us another, similar certificate from the same CA so we can try this out. We had the idea to establish a Vodia Root CA, so that we can make this easier for PBX deployments. But the core problem remains that all users need then to trust the Vodia Root CA, which is even more hassle. That is why that dummy built-in certificate is still in there. On a side note, the whole thing around Internet certificates is badly broken IMHO. I few weeks ago I went through the list of "trusted Root CA" on my Android phone, it was shocking who this device is trusting. Maybe we do have a good chance getting on that list is as well! Quote Link to comment Share on other sites More sharing options...
koolandrew Posted February 11, 2016 Author Report Share Posted February 11, 2016 I am not sure why added the Vodia Root CA as it isnt assigned to the server, it is assigned to local host. I agree that the certificate thing is crap, but it doesnt help solve the problem. I turned on tls logging, and here is what i got 2] 16:37:38.348 TLS: Private and public key don't match Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 11, 2016 Report Share Posted February 11, 2016 Aha! That is a very important hint. The PBX is not able to match the private key with the top certificate (the private and the public key don't match up). We had that problem when the private key is encrypted, and, of course, if the keys really don't match. Can you double, triple check if you were using the right keys? So we are talking RSA keys with 2048 bits? What hash method? What you could do if you have an Apache running somewhere is trying to use the certs there and see if that works. Quote Link to comment Share on other sites More sharing options...
koolandrew Posted February 11, 2016 Author Report Share Posted February 11, 2016 We have used this setup for our website using apache, on routers, our mail server, but we cannot get it to work on the pbx, and it doesnt appear many others can either. Please just come clean with me, if you cant do it, you cant do it. I get the feeling that you know this already so just let me know and i will move on. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 12, 2016 Report Share Posted February 12, 2016 I think the problem is that the key is a PKCS#8 key, while the PBX expects a PKCS#1 key. That is the difference between BEGIN RSA PRIVATE KEY and BEGIN PRIVATE KEY. We will add code that in the next version the PBX will "eat" both versions. For now, please convert the #8 into #1 using openssl: openssl rsa -in pkcs8.pem -out pkcs1.pem Quote Link to comment Share on other sites More sharing options...
koolandrew Posted February 18, 2016 Author Report Share Posted February 18, 2016 We converted the private key as suggested, imported both our wildcard certificate and the private key as "Server certificate chain + private key", rebooted the PBX and it worked! Thanks you so much for bearing with us, problem solved! Kudos! I think the problem is that the key is a PKCS#8 key, while the PBX expects a PKCS#1 key. That is the difference between BEGIN RSA PRIVATE KEY and BEGIN PRIVATE KEY. We will add code that in the next version the PBX will "eat" both versions. For now, please convert the #8 into #1 using openssl: openssl rsa -in pkcs8.pem -out pkcs1.pem Quote Link to comment Share on other sites More sharing options...
Mr VoBI Posted October 8, 2017 Report Share Posted October 8, 2017 Hello, I have spent a month trying to get this done with iPage and Comodo SSL. I have had no luck at all. I am happy to pay to be shown how it is to be done. Thanks. Quote Link to comment Share on other sites More sharing options...
RoadRunnR Posted May 8, 2020 Report Share Posted May 8, 2020 @Vodia PBX still monitoring this thread? I've run into a similar problem and it turns out that it appears to be impossible to replace the certificate that is presented when a HTTPS request does not include a SNI (server name indication). When a SNI is present the correct ACME (or manual) certificate is used, but when no SNI extension is present it always falls back to the build in Vodia certificate. Is there any way to make the PBX always use the provisioned ACME certificate? Quote Link to comment Share on other sites More sharing options...
Support Posted May 8, 2020 Report Share Posted May 8, 2020 If, 1. You have the ACME certificate setting turned on. 2. You are not using any wildcard or external certificates of your own. 3. If your domains have a FQDN name and is accessible on port 80 Then it should always use the ACME certs and auto-renew as long as above conditions are always satisfied. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 8, 2020 Report Share Posted May 8, 2020 10 hours ago, RoadRunnR said: @Vodia PBX still monitoring this thread? I've run into a similar problem and it turns out that it appears to be impossible to replace the certificate that is presented when a HTTPS request does not include a SNI (server name indication). When a SNI is present the correct ACME (or manual) certificate is used, but when no SNI extension is present it always falls back to the build in Vodia certificate. Is there any way to make the PBX always use the provisioned ACME certificate? Practically everything today uses SNI—because practically all web traffic is on multi-home web servers. There are unfortunately still some SIP phones out there that did not have SNI turned on. In a nutshell, there is no way to use them with TLS in a secure (validate certificate) way if there are more than one tenant on the hosted PBX. The only way to get this working is to certificate validation off. Quote Link to comment Share on other sites More sharing options...
RoadRunnR Posted May 11, 2020 Report Share Posted May 11, 2020 I did manage to get our phones (SNOM 720/725/760) to use SNI by forcing the use of DNS names instead of IPs with Admin Level / Phones / Settings /Use domain name instead of IP address = ON Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 12, 2020 Report Share Posted May 12, 2020 Yes—certificates work only with DNS addresses. snom does this for a long time. This is in /reg_pnp_settings.htm setting "Use domain name instead of IP address". Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.