Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
Can you try using mqtt.fx and check whether you are able to connect to mosquitto broker? This does seem to be a mosquitto issue rather than a WICED mqtt/tls issue because I am able to use some other brokers successfully in my setup.
Modify the CLIENT_AP_SSID/CLIENT_AP_PASSPHRASE Wi-Fi credentials in the wifi_config_dct.h header file to match your Wi-Fi access point
Modify the MQTT_BROKER_ADDRESS with your MQTT broker (By default WICED uses test.mosquitto.org). If you intend to use a different broker you need to change the MQTT_BROKER_ADDRESS and as the discussion is centered on secure_mqtt, you need to get the CA certificate from broker website and put it in 43xxx_Wi-Fi/resources/apps/secure_mqtt (in WICED understandable format. please refer to the .cer file for already present in the directory for further clarifications)
To debug a connection issue with the broker and you seem to think that it is an issue with WICED MQTT library, try connecting to the broker using some other MQTT client. I personally use mqttfx app downloadable from https://mqttfx.jensd.de/ to determine whether the broker is functional or not. Once I understand the issue is with WICED MQTT library (not with the broker as inferred from the independent mqtt client), there are various ways to debug this. One of the most common places to start looking would be TLS, by enabling the TLS logs in mbedTLS as mentioned in Debugging TLS in WICED