Hi Gregg, For sure the file is read. It works when the file contents indicate a pre-shared key type of security. When it is changed to certificate based I get the handshake error.
Caveat: I'm using statically configured stuff - no dynamic provisioning, > each side is already provisioned. I have tried both. In your case, do you use pre-shared key (PSK) or certificates? If the second, could you share the code? On Mon, Dec 31, 2018 at 10:55 PM Gregg Reynolds <d...@mobileink.com> wrote: > Fwiw, I got this error, and it was because I did not provide the cbor file > that gets read. Check the logs to make sure your cbor files actually get > read successfully. It could be something as simple as a bad path. > > Hth > > Gregg > > On Mon, Dec 31, 2018, 4:02 AM Khaled Elsayed <khaledi...@gmail.com wrote: > >> Hi Reporting on this: >> >>> So, I will re-visit this and test the following: >>> 1) non-provisioned sampleserver_mfg with proper certificate chain >>> 2) provisioningclient with proper certificate chain provisions the >>> sampleserver >>> (I re-confirm 1 and 2 already work great either with sample code and >>> certificates and also using my newly created certificates) >>> 3) Third client with proper certificates chain accesses the >>> sampleserver_mfg resources. >>> I have a feeling this will work. Will let you guys know tomorrow. >> >> >> Did not work. My feeling was wrong. Glad it did not. It would not be >> logical if it works actually. Still the same issue. The provisioningclient >> works all right and now owns the server_mfg. If a second client uses a >> certificate to communicate with the server_mfg something needs to be called >> to init the ciphersuite associated with the DTLS connection. >> >> 56:55.797 DEBUG: OIC_SRM_CREDL: In InitCipherSuiteListInternal >> 56:55.797 DEBUG: OIC_SRM_CREDL: Out InitCipherSuiteListInternal >> 56:55.797 DEBUG: OIC_SRM_PKIX_INTERFACE: Out InitCipherSuiteList >> 56:55.797 DEBUG: OIC_CA_NET_SSL: Supported ciphersuites: >> 56:55.797 ERROR: OIC_CA_NET_SSL: *No ciphersuites configured, secure >> connections will fail* >> 56:55.797 DEBUG: OIC_CA_NET_SSL: Out SetupCipher >> 56:55.797 ERROR: OIC_CA_NET_SSL: Failed to set up cipher >> 56:55.797 DEBUG: OIC_CA_NET_SSL: In DeleteSslEndPoint >> 56:55.797 DEBUG: MBED_TLS: => free >> 56:55.797 DEBUG: MBED_TLS: <= free >> 56:55.797 DEBUG: OIC_CA_NET_SSL: In DeleteCacheList >> 56:55.797 DEBUG: OIC_CA_NET_SSL: Out DeleteCacheList >> 56:55.797 DEBUG: OIC_CA_NET_SSL: Out DeleteSslEndPoint >> 56:55.797 ERROR: OIC_CA_NET_SSL: *TLS handshake failed* >> 56:55.797 ERROR: OIC_CA_IP_ADAP: CAencryptSsl failed! >> >> >> >> On Sun, Dec 30, 2018 at 3:57 PM Khaled Elsayed via Lists.Iotivity.Org >> <khaledieee=gmail....@lists.iotivity.org> wrote: >> >>> Hi Gregg. I am not using any new code. Just the code in >>> ~/iotivity/examples/OCFSecure and also the code in and the code in >>> resource/csdk/security/provisioning/sample. I just created new >>> certificates/private keys and json files for a client and server. The >>> certificates and json files work great for the provisioningclient and >>> sampleserver_mfg. So, I don't have a bug in the certificate and their usage >>> in the json files. My problem is if I get one client and one server which >>> are pre-provisioned ad their json uses certificate chain based >>> authentication, the secure DTLS is not established. I suspect that this is >>> probably just the model. the server should be provisioned first with a >>> certificate holding client after which it can provide access. But I am not >>> sure why or if this interpretation is correct. >>> >>> So, I will re-visit this and test the following: >>> 1) non-provisioned sampleserver_mfg with proper certificate chain >>> 2) provisioningclient with proper certificate chain provisions the >>> sampleserver >>> (I re-confirm 1 and 2 already work great either with sample code and >>> certificates and also using my newly created certificates) >>> 3) Third client with proper certificates chain accesses the >>> sampleserver_mfg resources. >>> I have a feeling this will work. Will let you guys know tomorrow. >>> >>> I generate the certificates and keys using the utility certgenerator >>> that also comes with the provisioning code. It is a very straight-forward >>> tool. Then I process the output further with openssl to put the >>> certificates in DER format to fill the JSON files. >>> >>> Let me know if there is anything else you need to restart on this. >>> >>> BR, >>> >>> Khaled >>> >>> >>> >>> On Thu, Dec 27, 2018 at 10:40 PM Gregg Reynolds <d...@mobileink.com> >>> wrote: >>> >>>> >>>> >>>> On Mon, Dec 10, 2018, 1:02 AM Khaled Elsayed <khaledi...@gmail.com >>>> wrote: >>>> >>>>> Hi Gregg, >>>>> >>>>> No unfortunately. I will have a second look today but If I could not, >>>>> I will proceed using the non-certificate based shared key credential >>>>> supporting a limited number of clients for the time being >>>>> >>>> >>>> Do you have any code you can share? I'm gearing up to work on this >>>> sorta stuff in January. >>>> >>>> G >>>> >>>>> _._,_ >>>>> >>>>>> >>> >>> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10111): https://lists.iotivity.org/g/iotivity-dev/message/10111 Mute This Topic: https://lists.iotivity.org/mt/28611921/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
