Caught configuration exception

I have not done an 11.x install yet, and this seems like a obvious question, but you didn't state anything about licensing - did you license the box by sending the dossier up to the license server and applying the license -

 

 

what happens with the reloadlic command ?

Where did you get the configuration files from? Did you copy them from an existing system?

 

To me it looks like the configuraion file bigip.conf is trying to reference a certificate file called dtca-bundle.crt in the Common folder which is not there.

 

So my guess is that you either grab that file from the source device that the configuration files are from and copy it into the /Common folder, or edit the bigip.conf to find where it is referencing this file and comment that bit out and run the config load again.

 

It actually needs to go into the folder (you wont find a /Common folder):

 

/config/filestore/files_d/Common_d/certificate_d

 

Looks like the files in there have a special format, so you will need to copy the file in the format that it is expecting from the source device.

 

On that note, you may want to copy the whole filestore folder across from the source device.

 

That cert is related to ConfigSync. I'd suggest you license the device, provision if necessary and renew the device certificate and try again.

I'm not licensing yet (I'll licensing at customer site). this happen when i finished install and try to load default config (after installation complete) by "tmsh load sys config".

I'm not sure you can load a configuration without licensing and provisioning?

I agree - if your not licensed for LTM it isn't provisioned, and therefore your not going to be able to load a config.

When running the command 'tmsh load sys config verfy' I get the following error message: Oct 15 12:39:40 kh-l2-gops err mcpd[7428]: 01070712:3: Caught configuration exception (0), _identify_jobs_todo:(/Common/dtca-bundle.crt) :Failed: name (/Common/dtca-bundle.crt) No copy in trash-bin to restore from. - sys/validation/FileObject.cpp, line 3065. I looked in the /config/bigip_base.conf file and noticed the following concerning the dtca files: cm cert /Common/dtca-bundle.crt { cache-path /config/filestore/files_d/Common_d/trust_certificate_d/:Common:dtca-bundle.crt_10 checksum SHA1:1253:d2530d5fd35f22dbe4dac72ba2bdb34e3dff6581 revision 10 } cm cert /Common/dtca.crt { cache-path /config/filestore/files_d/Common_d/trust_certificate_d/:Common:dtca.crt_9 checksum SHA1:1253:d2530d5fd35f22dbe4dac72ba2bdb34e3dff6581 revision 9 } cm cert /Common/dtdi.crt { cache-path /config/filestore/files_d/Common_d/trust_certificate_d/:Common:dtdi.crt_11 checksum SHA1:1237:1e0fbe6b7ce9eabb66d72243c89a2128a5e75c43 revision 11 } } cm key /Common/dtca.key { cache-path /config/filestore/files_d/Common_d/trust_certificate_key_d/:Common:dtca.key_9 checksum SHA1:1675:793dd459dd6ac574535710d95975d7152c0b636a revision 9 } cm key /Common/dtdi.key { cache-path /config/filestore/files_d/Common_d/trust_certificate_key_d/:Common:dtdi.key_4 checksum SHA1:1675:1917a2a4fc12a4d3b0c75b8ea52f18618f3ccf31 revision 4 } I then looked in the /config/filestore/files_d/Common_d/trust_certificate_d and saw the following files: :Common:dtca-bundle.crt_11255_10 :Common:dtca.crt_11257_9 :Common:dtdi.crt_11259_11 and /config/filestore/files_d/Common_d/trust_certificate_key_d and saw the following files: :Common:dtca.key_11271_9 :Common:dtdi.key_11273_4 So I went into the bipip_base.conf and modified the following to reflect the correct file names. cm cert /Common/dtca-bundle.crt { cache-path /config/filestore/files_d/Common_d/trust_certificate_d/:Common:dtca-bundle.crt_11255_10 checksum SHA1:1253:d2530d5fd35f22dbe4dac72ba2bdb34e3dff6581 revision 10 } cm cert /Common/dtca.crt { cache-path /config/filestore/files_d/Common_d/trust_certificate_d/:Common:dtca.crt_11257_9 checksum SHA1:1253:d2530d5fd35f22dbe4dac72ba2bdb34e3dff6581 revision 9 } cm cert /Common/dtdi.crt { cache-path /config/filestore/files_d/Common_d/trust_certificate_d/:Common:dtdi.crt_11259_11 checksum SHA1:1237:1e0fbe6b7ce9eabb66d72243c89a2128a5e75c43 revision 11 } } cm key /Common/dtca.key { cache-path /config/filestore/files_d/Common_d/trust_certificate_key_d/:Common:dtca.key_11271_9 checksum SHA1:1675:793dd459dd6ac574535710d95975d7152c0b636a revision 9 } cm key /Common/dtdi.key { cache-path /config/filestore/files_d/Common_d/trust_certificate_key_d/:Common:dtdi.key_11273_4 checksum SHA1:1675:1917a2a4fc12a4d3b0c75b8ea52f18618f3ccf31 revision 4 } Then when I ran the 'tmsh load sys config verify' it passed without that error. I hope this may be helpful to someone that is having this issue. F5 says there is a bug ID for this and are going to update me once they find it. I was upgrading from 11.2 to 11.4.1HF4 when this issue occured.

Hi,

 

the issue regarding the missing dtca.key file is related to the .ucs archive.

 

Please check \var\tmp\filestore_temp\files_d\Common_d\trust_certificate_key_d\ in the .ucs archive if the device trust CA key and device trust device identity keys are contained or not.

 

This might be the case, if you decide, not to store private keys in the archive.

 

The setting obviously does not only affect the storage of SSL private keys to be used by LTM.

 

(Just faced this issue in a client´s environment.)

 

There is a related solution on Ask F5 SOL14979 as well.

 

Thanks, Stephan