Removing Internals>Network>Certificate - those errors coming from chapsd are more significant, and indicate that dkrahn@ may know what's up.

+apronin

aashutoshk@ -- Can you please document the repro steps and attach (or point to) the certificate that fails? Also, please run "chaps_debug" in crosh and then attempt the test again and attach logs.

Repro Steps:
1) Go to chrome://settings/certificates page.
2) Click "Import and bind to Device" button, select certificate (attached) and enter the password ("chromeos")

Attached: logs with chaps_debug and certificate. 

Deleted: openvpn_client.p12 3.2 KB

openvpn_client.p12 3.2 KB Download

Deleted: log-030117-183011.tar.gz 2.5 MB

log-030117-183011.tar.gz 2.5 MB Download

Thank you, aashutoshk@.
 
Still the same, as expected:
2017-03-01T18:29:40.420979-08:00 DEBUG chapsd[1683]: IN: attributes={CKA_CLASS=CKO_PRIVATE_KEY, CKA_KEY_TYPE=CKK_RSA, CKA_ID={142, 255, 42, 15, 180, 118, 248, 251, 197, 190, 86, 246, 63, 44, 180, 90, 74, 184, 143, 173}, CKA_MODULUS=***, CKA_PRIVATE_EXPONENT=***, CKA_PUBLIC_EXPONENT=***, CKA_PRIME_1=***, CKA_PRIME_2=***, CKA_EXPONENT_1=***, CKA_EXPONENT_2=***, CKA_COEFFICIENT=***, CKA_DECRYPT=Yes, CKA_DERIVE=No, CKA_SIGN=Yes, CKA_SIGN_RECOVER=Yes, CKA_UNWRAP=Yes, CKA_TOKEN=Yes, CKA_PRIVATE=Yes, CKA_SENSITIVE=Yes}
2017-03-01T18:29:40.421187-08:00 ERR chapsd[1683]: Minimum modulus size is: 256

The private key modulus size in this cert is indeed 128 bytes.

Darren, what was the key reason to restrict the min key size to 256 bytes for TPM 2.0? Does anything prevents us from importing a smaller key?
I haven't experimented yet with this cert - I'll check if we can allow it, and if it leads to any issues in trunks::TpmUtility routines.

We can, but a 1024-bit key should be considered insecure. I wouldn't go to a lot of effort to import to the TPM, the TPM spec discourages support for less than 2048-bits. I'd say that if we want to support these keys for compatibility we should do like we do for other key sizes not supported by the TPM and wrap them in software with a TPM key.

I see an issue connecting to openvpn service on snappy and pyro device only. The certificates (attached) has a private key modulus size of 256 bytes. Importing the certificate in the certificate manager is not an issue but trying to connect throws an internal error.  

Can you check the logs to see, if this is somehow related or else will open a separate issue?

Attached: 
1) Logs 
CHROMEOS_RELEASE_DESCRIPTION=9202.43.0 (Official Build) beta-channel snappy 
Version 57.0.2987.85 beta (64-bit)

2) Certificate (password:"password")
Note: Kevin device (9202.43.0) connected to the service using the same certificate without any issue. 

Deleted: log-030217-142544.tar.gz 1.1 MB

log-030217-142544.tar.gz 1.1 MB Download

Deleted: openvpn256.p12 2.4 KB

openvpn256.p12 2.4 KB Download

Re #7. Now it's a different issue. The cert is (usually successfully) used for signing. But establishing the connection with the OpnVPN server seems to be closed at AUTH step. E.g. one of such cases from net.log:
2017-03-02T22:24:31.276215+00:00 INFO shill[1615]: [INFO:openvpn_management_server.cc(390)] OpenVPN state: AUTH
2017-03-02T22:24:33.084018+00:00 ERR openvpn[1221]: Connection reset, restarting [0]
2017-03-02T22:24:33.084338+00:00 NOTICE openvpn[1221]: SIGUSR1[soft,connection-reset] received, process restarting

There is a known OpenVPN/OpenSSL issue with slightly different symptoms (there the connection times out), but that may depend on the OpenVPN server. Quite possible, it's what we see in this case as well.

There are also EREMOTEIO errors seen in /var/log/messages (known issue), which lead to some of the signing failures during OpenVPN connections:
2017-03-02T19:51:22.074842+00:00 ERR trunksd[2211]: TPM: Error writing to TPM handle.: Remote I/O error
2017-03-02T19:51:22.075538+00:00 ERR kernel: [  740.638154] tpm tpm0: tpm_transmit: tpm_send: error -121
2017-03-02T19:51:22.076066+00:00 ERR chapsd[2374]: Error fetching salting key public info: TRUNKS_RC_WRITE_ERROR
2017-03-02T19:51:22.076096+00:00 ERR chapsd[2374]: Error encrypting salt: TRUNKS_RC_WRITE_ERROR
2017-03-02T19:51:22.076114+00:00 ERR chapsd[2374]: Error starting an AuthorizationSession: TRUNKS_RC_WRITE_ERROR
2017-03-02T19:51:22.076607+00:00 ERR shill[1620]: [0302/115122:ERROR:chaps.cc(1070)] C_Sign - CKR_FUNCTION_FAILED
2017-03-02T19:51:22.079026+00:00 ERR shill[1615]: [ERROR:openvpn_management_server.cc(252)] Not implemented reached in bool shill::OpenVPNManagementServer::ProcessNeedPasswordMessage(const string &): Unsupported need-password message: >PASSWORD:Need 'User TPM Token 0b331743a26ace21 token' password

And a couple of Chrome crashes like
2017-03-02T19:53:50.658550+00:00 INFO kernel: [  889.216889] chrome[9027]: segfault at 0 ip 00005af536a84f3c sp 00007ffe06fe33b0 error 4 in chrome[5af53090a000+7013000]
2017-03-02T19:53:50.694071+00:00 WARNING crash_reporter[9293]: [user] Received crash notification for chrome[9027] sig 11, user 1000 (ignoring call by kernel - chrome crash; waiting for chrome to call us directly)

But those things are pretty early in the process, and even if they led to OpenVPN connection failure early on, that shouldn't lead to inability to connect to OpenVPN on the following attempts.
But it'd be interesting to see if something changes after reboot.

Connecting to VPN  service continues to fail on Electro(Reef) R57-9202.53.0. 

If we can rule out that EREMOTEIO errors are not causing AUTH step to fail, I can open a new issue for the network team to look into this. 

Adding stable-blocker, remove if not applicable. 

Hard to rule out w/o a log, but EREMOTEIO workaround has landed in 9202.52.0, so EREMOTEIO shouldn't be the cause here anymore.

There is already an issue for OpenVPN errors: https://b.corp.google.com/issues/35585042

That bug is not marked as blocker for M-57 because it affects only new devices, and those are expected to AU to 58 immediately. Marked as blocker for M-58 for that reason. So, I'd recommend updating labels accordingly here as well.

CL https://chromium-review.googlesource.com/c/577147 is pending review.
Verified that with that CL the cert from comment #4 is successfully imported.

The original issue with <256 bytes certs is a duplicate of  issue 726057 .
OpenVPN problems from comment #8 may be a duplicate of b/35585042.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/0636f98673421e529aac3ca00057c46419955742

commit 0636f98673421e529aac3ca00057c46419955742
Author: Andrey Pronin <apronin@chromium.org>
Date: Wed Jul 26 23:46:51 2017

chaps: use tpm-specific key size ranges to allow 1024 keys on tpm2

Before the change, in tpm2 case, chaps refused to wrap RSA keys
less than 2048 bits in size at the tpm utility layer, even though
the upper layers expected the tpm to support it.
This change introduces requesting min and max supported RSA key
sizes from the tpm utility layer. The min supported size for tpm2
is set to 1024 bits.

BUG= chromium:726057 
BUG= chromium:697671 
TEST=0) Unit tests.
     1) Generate 1024-bit RSA keypair and certificate:
        openssl req -nodes -x509 -sha1 -newkey rsa:1024 -keyout /tmp/priv.key \
                    -out /tmp/cert.crt
        openssl pkcs12 -export -out /tmp/cert.pfx -inkey /tmp/priv.key \
                       -in /tmp/cert.crt
        openssl rsa -pubout -in /tmp/priv.key -out /tmp/pub.key
        openssl pkcs8 -inform pem -outform der -in /tmp/priv.key \
                      -out /tmp/priv.der -nocrypt
     2) Verify that the generated private key is successfully imported:
        p11_replay --import --path=/tmp/priv.der --type=privkey \
                   --id=aaaaaa
     3) Verify that the imported private key can be used for signing
        (emerge and deploy opensc for pkcs11-tool):
        echo "ABCDEF" > /tmp/1.txt
        pkcs11-tool --module=`ls /usr/lib**/libchaps.so` --slot=0 \
                    --id=aaaaaa --sign -i /tmp/1.txt -o /tmp/1.sig \
                    -m SHA1-RSA-PKCS
        openssl dgst -sha1 -verify /tmp/pub.key -signature /tmp/1.sig \
                     /tmp/1.txt
     5) Verify that the generated cert.pfx can be imported through
        Settings > Manage certificates > Import and Bind.

Change-Id: I2591af496b9cf777b8b6c5a26426316127f8288b
Reviewed-on: https://chromium-review.googlesource.com/577147
Commit-Ready: Andrey Pronin <apronin@chromium.org>
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>

[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/tpm2_utility_impl.cc
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/tpm_utility_impl.h
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/tpm_utility.h
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/session_test.cc
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/session_impl.cc
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/tpm_utility_mock.h
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/tpm2_utility_impl.h

This continues to fail. Eve 9765.51.0

The CL landed in 9782.0.0, so a fail in 9765.51.0 is expected.

Also, what do we see in logs for eve now? OpenVPN issues from b/35585042 are still there. Even if we pick the fix for 1024 bit certs into M61, the test may continue to fail.

If the error is with a 256 byte cert, and the logs are similar to comment #8, needs to be merged into b/35585042.

Closing "Adding certificates with key size < 256 bytes fail". If there are other cert-related issues, let's open specific bugs for them.

Assigning it to aashutosh@ for verification.

Verified on Eve R63-10032.25.0.