For those of you getting the message about "incomplete trust chain and the certificate has no associated CRL", the CRL is a Certificate Revocation List. You should be able to obtain that from the same source as you CA certificate. Assuming these are local domain certificates and you have the necessary permissions in the domain you may be able to obtain it yourself. For a Windows certificate server the URL would be <FQDN of domain controller/certificate server>/certserv. For example, for a fictional domain called abc.com with a domain controller named dc it would be https://dc.abc.com/certsrv. Once you get there you should see an option to Download a CA certificate, certificate chain, or CRL. On the next screen that comes up change the Encoding methos to Base 64 then select Download latest base CRL. In Certificate Management in the CMA there is an option to Upload Certificate Revocation List.
As far as the @0@ error, that is indicative of a database corruption but manipulating certificates should have nothing to do with that. However, I did find one Service Request in our database where the issue was resolved by reverting to the default certificate.
So if you are getting both the "incomplete trust chain and the certificate has no associated CRL" error and the "@0@" error then either get a CRL from your certificate authority or revert back to the default certificate.
Do you mean this procedure
Will this work with the self signed certificate now that has expired?
I have been trying to get my CMA into the same state where I get the @0@ errors but I can't.
On version 6.2.7, if the CMA has just the self-signed certificate installed and you try to install a new host certificate without first installing a CA certificate it will fail due the incomplete trust chain. If you install the CA certificate first and then the host certificate and get the CMA considers the certificates invalid due to the missing CRL, you are stuck on the Certificate Management screen until you fix the problem. You can't reboot. At that point you either have to install a CRL or revert back to the self-signed certificate. I can't say the same for older versions.
Will the procedure in the referenced post work? I don't see why not. It seems like recreating the CSR and host certificate just to delete them is overkill to me. Just clicking on the Revert to Default Certificate action should be sufficient.
The first steps I think they are not needed because we have done them already.
We produced a CSR, signed it with the CA and insert it back. Following the rest of the steps is the way to restore the users database.
Well I have done the following
1) From certificate management I used the option at the left menu to Revert to Default Certificate
2) Some warnings popped up, pressed ok and at the final screen it said that all invalid certificates must be deleted before restarting server to apply the default certificate
3) I deleted the host certificate first, then the intermediate and finally the root
4) After deleting the root certificate a pop up appeared saying if I want tor restart the system now or keep working on certificates. I chose to reboot and after ten minutes the system had returned and I could see the users.
The problem now is that I have also some cma desktop users that cannot login.
Could this be happening due to the expired default certificate?
Also my ca informed me that the certificate was sha256 and it is the only option that he has.
Although Mike you have informed me that it is not supported the certificate was inserted without a hickup.
Visiting the cma, after rebooting, produced a valid ssl session and I could see the certificate in my browser.
Well everything else didn't work but still the system didn't check which sha version was the certificate created on.
From what I undestand after checking the logs the database is encrypted or secured and the public key of the certificate is used to decrypt it or connect to it. Does the limitation to sha1 comes from this connection (to the mysql) and many other subsystems that can use only sha1 encryption?
I am asking because the apache didn't produce any errors and used the certificate.
So do you mean that a CRL is needed after all?
If I have to upload the CRL, does the certificate need to have a CRL Distribution Point field or not?
Don't get hung up on the SHA-1 vs SHA-256. SHA is Secure Hash Algorathm. It is used to create a hash of the CA certificate key so that the key can be validated as authentic. SHA-1 is the older version. It created a 160 bit hash. SHA-2 is the successor to SHA-1. It uses a family of different has sizes. 256 bit hashes is one of them which is why you will often see SHA-2 referred to as SHA-256. They are the same thing. The fact that the CMA will accept a certificate with a SHA-256 bit hash tells you that it has no problem using it. If it could interpret it it wouldn't accept the certificate.
You say that "some" of your CMA Desktop users can't sign in. If that was related to the certificate I would think that none of them would be able to log in.
For the CRLs, I have yet to see a CA certificate that didn't have a CRL distribution point associated with it. That doesn't mean it isn't possible. If there isn't one then the CMA most likely wouldn't ask you for one. In the cases where the CRL Distribution Point is defined in the CA certificate, if the CMA asks you to upload one it means it could resolve the distribution point. CRLs, like certificates in general, can be encoded in one of two ways, DER or PEM. DER is a binary encoded format that the CMA doesn't understand. In fact, I'm not aware of any Polycom infrastructure products that will accept it. PEM files are Base64 encoded files. That is the format that we want. What can happen with CRLs is that the CMA is going to the Distribution Point to retrieve the CRL but it is being provided a DER encoded file which it doesn't understand and that is why it is askign for a CRL to be manually uploaded. Bottom line is that if it doesn't ask for a CRL, you don't need one.
Hello MikeB, this is Sotiris' colleague.
First, many thanks for elaborating on this.
Update: "all" of our CMA Desktop users can't sign in (not "some"), when the CMA is loaded with just the expired (self-signed) certificate. Till the last day of certificate expiration, CMA Desktop client connections to the CMA server have been alright.
Sitrep: so here's where we stand now,
We try to load a new CA certificate, with SHA-256 bit hash and no CRL. Certificate seems to be accepted by the CMA. No alarms re the SHA-256 bit hash or missing CRL.
But then we end up with the corrupted database issue, the @0@pop-up, users have disappeared from CMA screens.
So we revert to the self-signed certificate, delete the imported CA certificate (all 3 of them, root, intermediate, host), reboot the CMA and...
CMA comes up with the expired certificate, database is OK, CMA desktop users are visible in the system but cannot sign in.
We have tried the above more than once. Seems we are in a dead end now. Any idea would be much appreciated.
The tough part about this is that I can't duplicate the @0@ error when I use local domain certificates. Let me do some more testing and see if I can come up with something.
Thank you again for the tremendous help, checking the logs I am getting some errors.
First of all in the EXXX_LOG3 I am getting these messages
13/Feb/2019:08:27:12:333 +02:00 ERROR Connected network adapter appears to have an IP conflict 13/Feb/2019:08:27:12:333 +02:00 MAJOR Get network settings for adapter: IP, Subnet[0.0.0.0], Gateway 13/Feb/2019:08:27:12:630 +02:00 MAJOR Get network settings for adapter: IP[192.168.1.20], Subnet[255.255.255.0], Gateway[192.168.1.1] 13/Feb/2019:08:27:12:755 +02:00 MAJOR Get network settings for adapter: IP[192.168.1.20], Subnet[255.255.255.0], Gateway[192.168.1.1] 13/Feb/2019:08:27:12:864 +02:00 ERROR Connected network adapter appears to have an IP conflict
Although from the web interface I can set an ip, the cma4000 appliance seems to have two nics, adapter and adapter.
The ip conflict message is not defining which interface refers to. Can you give any hint on this?
Also these messages are repeating every minute in the Jserver.log
12/Feb/2019:22:47:44:211 +0200|ERROR|pool-3-thread-12|DeviceDataGetter|(DmPollTask-10326_43927) Failed to determine device type from system.xml. MODELCODE was null 12/Feb/2019:22:47:44:211 +0200|ERROR|pool-3-thread-12|ContactEventPoll|(DmPollTask-10326_43927) -------- BAD DRIVER STATUS [PARSE_ERROR] for device [ContactEventPoll[Justanametohideoriginal5]] 12/Feb/2019:22:48:25:243 +0200|ERROR|pool-3-thread-17|ContactEventPoll|(DmPollTask-10341_44005) -------- BAD DRIVER STATUS [FUNCTION_NOT_SUPPORTED] for device [ContactEventPoll[Justanametohideoriginal4]] 12/Feb/2019:22:50:10:274 +0200|ERROR|pool-3-thread-17|ContactEventPoll|(DmPollTask-10343_44196) -------- BAD DRIVER STATUS [FUNCTION_NOT_SUPPORTED] for device [ContactEventPoll[Justanametohideoriginal3]] 12/Feb/2019:22:51:51:024 +0200|ERROR|pool-3-thread-4|ContactEventPoll|(DmPollTask-10311_44378) -------- BAD DRIVER STATUS [FUNCTION_NOT_SUPPORTED] for device [ContactEventPoll[Justanametohideoriginal2]] 12/Feb/2019:22:51:54:087 +0200|ERROR|pool-3-thread-2|ContactEventPoll|(DmPollTask-10317_44388) -------- BAD DRIVER STATUS [FUNCTION_NOT_SUPPORTED] for device [ContactEventPoll[Justanametohideoriginal1]]
and finally in the DeviceManager.log I am getting these for the cma desktop users
12/Feb/2019:16:04:40:587 +0200|DEBUG|main|IDmInternalDeviceManager|(WebApplicationContext_0) deviceMap put =[DeviceData [deletedforsecurityresons]] was [null] 12/Feb/2019:16:04:40:587 +0200|INFO |main|IDmInternalDeviceManager|(WebApplicationContext_0) device put into cache [DeviceData [deletedforsecurityresons]] 12/Feb/2019:16:04:40:587 +0200|DEBUG|main|IDmInternalDeviceManager|(WebApplicationContext_0) pnidMap put = was [null] 12/Feb/2019:16:04:40:587 +0200|DEBUG|main|IDmInternalDeviceManager|(WebApplicationContext_0) serialNumberMap put [secret-serial-number]= was [null]
I have deleted all sensitive information but I think you can get a glimpse.
This is a completely different issue from the self-signed certificate issue that this thread is for and really should be in it's own thread.
All I can say about it now is that the CMA server has 4 ethernet ports. Unless you are running the CMA in an HA configuration you should only be using the first port. The adapter numbers, 2 and 7, are assigned by Windows and don't have a specific meaning. All of the adapters come with DHCP enabled by default out of the box until you assign the IP address. Adapter 2 in your log shows no IP address, subnet mask or gateway which means it couldn't get an address from a DHCP server. Adapter 7 is complaining about an IP conflict which would have me looking for some other device on your network using the same address as the CMA.