If the certificate's format was valid, but we're asked to refer to it by
paths instead of using the raw data, 'data' would be leaked.

==23089== 8,232 (40 direct, 8,192 indirect) bytes in 1 blocks are definitely lost in loss record 5,109 of 5,123
==23089==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089==    by 0x39B905488E: g_malloc (gmem.c:159)
==23089==    by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089==    by 0x39B9024539: g_array_sized_new (garray.c:195)
==23089==    by 0x31FC0146EA: file_to_g_byte_array (crypto.c:319)
==23089==    by 0x31FC01543B: crypto_load_and_verify_certificate (crypto.c:606)
==23089==    by 0x31FC01ED26: nm_setting_802_1x_set_client_cert (nm-setting-8021x.c:819)
==23089==    by 0xC6944A4: eap_tls_reader (reader.c:2316)
==23089==    by 0xC692756: fill_8021x (reader.c:2714)
==23089==    by 0xC696151: wireless_connection_from_ifcfg (reader.c:2832)
==23089==    by 0xC698E3A: connection_from_file (reader.c:4316)
==23089==    by 0xC69135C: nm_ifcfg_connection_new (nm-ifcfg-connection.c:119)
==23089==
==23089== 8,352 (160 direct, 8,192 indirect) bytes in 4 blocks are definitely lost in loss record 5,110 of 5,123
==23089==    at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089==    by 0x39B905488E: g_malloc (gmem.c:159)
==23089==    by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089==    by 0x39B9024539: g_array_sized_new (garray.c:195)
==23089==    by 0x31FC0146EA: file_to_g_byte_array (crypto.c:319)
==23089==    by 0x31FC01543B: crypto_load_and_verify_certificate (crypto.c:606)
==23089==    by 0x31FC01E5E6: nm_setting_802_1x_set_ca_cert (nm-setting-8021x.c:538)
==23089==    by 0xC694DD8: eap_peap_reader (reader.c:2358)
==23089==    by 0xC692756: fill_8021x (reader.c:2714)
==23089==    by 0xC696151: wireless_connection_from_ifcfg (reader.c:2832)
==23089==    by 0xC698E3A: connection_from_file (reader.c:4316)
==23089==    by 0xC69135C: nm_ifcfg_connection_new (nm-ifcfg-connection.c:119)