Feedback reports@

https://listnr.corp.google.com/report/85729449409

https://listnr.corp.google.com/report/85729448940

two CA certs populated and OpenVPN connection is not successful with either of them.

Agree that showing the cert twice is weird, but do we know that it is correlated to VPN connection failing?
I.e., does it work if the cert is not imported through policy and manually, but just through policy?

So this is not nice UI, and we should fix it, but to me it seems that openvpn gets configured correctly. If I look at the feedback report and navigate to the openvpn service, which turns out to be /service/384 in the first report, I can see a correct PEM encoding of the certificate and when decoded:
pmarko@pmarko-glaptop0:~/Downloads/cert_twice$ openssl x509 -in pem.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            ef:8f:69:e0:a7:5f:9c:3e
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Easy-RSA CA
        Validity
            Not Before: May 12 06:03:50 2016 GMT
            Not After : May 10 06:03:50 2026 GMT
        Subject: CN = Easy-RSA CA
<...>
it seems to be the cert you have selected in the screenshot, so I'd think that the CA cert is configured correctly. I can see that we also configured a client cert:
Provider/3/OpenVPN.Pkcs11.ID: BBA7DF7ABCF1B5BDFE2C37C2D21C93CC570804F0

and from our logging that this indeed corresponds to a hardware-backed client [15361:15385:1017/134615.490646:INFO:nss_cert_database_chromeos.cc(172)] UserCertLogging: Cert with issuer=Easy-RSA CA, cert_slot_id=1, is_hw_backed=1, is_on_system_slot=0, key_slot_id=1, key_pkcs11_id=BBA7DF7ABCF1B5BDFE2C37C2D21C93CC570804F0

So, summarizing this, I suspect that the VPN connection issues have a different cause than showing the cert twice in the UI.

I'm not sure if these openvpn logs are of any help:
2018-10-17T13:34:06.964141-07:00 NOTICE openvpn[13198]: TCP/UDP: Preserving recently used remote address: [AF_INET]<IPv4: 54>:1194
2018-10-17T13:34:06.964238-07:00 NOTICE openvpn[13198]: Attempting to establish TCP connection with [AF_INET]<IPv4: 54>:1194 [nonblock]
2018-10-17T13:34:06.964722-07:00 INFO shill[1264]: [INFO:openvpn_management_server.cc(391)] OpenVPN state:  -> RESOLVE ()
2018-10-17T13:34:06.964820-07:00 INFO shill[1264]: [INFO:openvpn_management_server.cc(391)] OpenVPN state: RESOLVE -> TCP_CONNECT ()
2018-10-17T13:34:10.436643-07:00 WARNING shill[1264]: [WARNING:traffic_monitor.cc(221)] Congested tx queues detected, out-of-credits?
2018-10-17T13:34:14.971497-07:00 NOTICE openvpn[13198]: TCP connection established with [AF_INET]<IPv4: 54>:1194
2018-10-17T13:34:14.971535-07:00 NOTICE openvpn[13198]: TCP_CLIENT link local: (not bound)
2018-10-17T13:34:14.971564-07:00 NOTICE openvpn[13198]: TCP_CLIENT link remote: [AF_INET]<IPv4: 54>:1194
2018-10-17T13:34:14.971587-07:00 NOTICE openvpn[13198]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2018-10-17T13:34:14.971997-07:00 INFO shill[1264]: [INFO:openvpn_management_server.cc(391)] OpenVPN state: TCP_CONNECT -> WAIT ()
2018-10-17T13:34:14.973808-07:00 WARNING openvpn[13198]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2018-10-17T13:34:14.973828-07:00 INFO shill[1264]: [INFO:openvpn_management_server.cc(391)] OpenVPN state: WAIT -> AUTH ()
2018-10-17T13:34:24.202414-07:00 ERR openvpn[13198]: Connection reset, restarting [0]
2018-10-17T13:34:24.202619-07:00 NOTICE openvpn[13198]: SIGUSR1[soft,connection-reset] received, process restarting

Kirtika/Steven, would you be able to advise? I'll try to repro this locally today nevertheless.

Also, does the same VPN server work on M-69 ? I.e., is this a regression?

Also, do we have some VPN server that's available globally which I could use to try to repro here?

On 70.0.3538.70, I've been able to set up a local OpenVPN server and connect to it when importing the cert manually.

I've then pushed the cert through policy _and_ imported it manually and could see the cert appear twice in the selection.
However, the connection still worked fine for me:
https://drive.google.com/file/d/1FLWtwXVf3jOAtfx7EW-3YtTmgR7jpEEX/view?usp=sharing

https://drive.google.com/file/d/12sAyVYiEVFJon4G-NAf0Ph5iMIXxsIrL/view?usp=sharing

So I'd suggest to:
(1) keep this bug for the double-cert-display issue, and remove ReleaseBlock-Stable from it.
(2) investigate what's going on with the VPN connection in the test setup and file a separate bug for that if we suspect that it is due to a Chrome OS issue
(3) I've noticed that even though the CA cert is preselected by policy, I can edit it in the UI (but my selection doesn't seem to matter, the policy one is taken). We should file a separate (P-2) bug for that.

WDYT?

Removing RBS per comment #8. Adding M-71 so we don't lose track.

just through policy works fine. it is only when i also manually import the cert, it is an issue.

That's strange and I don't understand how that would be related yet, esp. since the certs seem to be configured correctly in shill in the logs as described in Comment #5.
Is it reproducible, i.e. if you create a new profile with only the policy-pushed CA it works, then you manually import the CA, reconnect, and now it doesn't work?

Could you send us the CA cert you're pushing the policy as PEM, so I can check if it's the same one that's being used in the logs?

Also, do we have some server-side logs or anything that would show us why exactly the connection did not succeed?

I could not reproduce this now ie., seeing double cert display but able to connect to openvpn with either of them. so keeping this bug for the double display issue. as per #8


Also, regarding #8-I've noticed that even though the CA cert is preselected by policy, I can edit it in the UI (but my selection doesn't seem to matter, the policy one is taken). We should file a separate (P-2) bug for that.  ->shall i open a seperate bug for this ?