starred/certbot-certbot
1
0
Fork 0
mirror of https://github.com/certbot/certbot.git synced 2026-08-01 02:44:21 +02:00
Code Issues Packages Projects Releases Wiki Activity

improve handling and ux of unexpected key type migration (#9200)

Browse Source 
* improve handling and ux of unexpected key type migration

* update unit tests

* update integration tests

* if --cert-name and --key-type are set, dont prompt
This commit is contained in:
alexzorin
2022-03-02 08:55:17 -08:00
committed by GitHub
parent f734e7a81c
commit 6e8f58e3f6
3 changed files with 87 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files
certbot-ci/certbot_integration_tests/certbot_tests/test_main.py
+27 -16
View File
@@ -540,35 +540,46 @@ def test_renew_with_ec_keys(context: IntegrationTestsContext) -> None:
'--key-type', 'ecdsa', '--elliptic-curve', 'secp256r1',
'--force-renewal', '-d', certname,
])
key1 = join(context.config_dir, "archive", certname, 'privkey1.pem')
assert 200 < os.stat(key1).st_size < 250 # ec keys of 256 bits are ~225 bytes
assert_elliptic_key(key1, SECP256R1)
assert_cert_count_for_lineage(context.config_dir, certname, 1)
context.certbot(['renew', '--elliptic-curve', 'secp384r1'])
assert_cert_count_for_lineage(context.config_dir, certname, 2)
key2 = join(context.config_dir, 'archive', certname, 'privkey2.pem')
assert_elliptic_key(key2, SECP384R1)
assert 280 < os.stat(key2).st_size < 320 # ec keys of 384 bits are ~310 bytes
assert_elliptic_key(key2, SECP384R1)
# We expect here that the command will fail because without --key-type specified,
# Certbot must error out to prevent changing an existing certificate key type,
# without explicit user consent (by specifying both --cert-name and --key-type).
with pytest.raises(subprocess.CalledProcessError):
context.certbot([
'certonly',
'--force-renewal',
'-d', certname
])
# When running non-interactively, if --key-type is unspecified but the default value differs
# to the lineage key type, Certbot should keep the lineage key type. The curve will still
# change to the default value, in order to stay consistent with the behavior of certonly.
context.certbot(['certonly', '--force-renewal', '-d', certname])
assert_cert_count_for_lineage(context.config_dir, certname, 3)
key3 = join(context.config_dir, 'archive', certname, 'privkey3.pem')
assert 200 < os.stat(key3).st_size < 250 # ec keys of 256 bits are ~225 bytes
assert_elliptic_key(key3, SECP256R1)
# When running non-interactively, specifying a different --key-type requires user confirmation
# with both --key-type and --cert-name.
with pytest.raises(subprocess.CalledProcessError) as error:
context.certbot(['certonly', '--force-renewal', '-d', certname,
'--key-type', 'rsa'])
assert 'Please provide both --cert-name and --key-type' in error.value.stderr
context.certbot(['certonly', '--force-renewal', '-d', certname,
'--key-type', 'rsa', '--cert-name', certname])
assert_cert_count_for_lineage(context.config_dir, certname, 4)
key4 = join(context.config_dir, 'archive', certname, 'privkey4.pem')
assert_rsa_key(key4)
# We expect that the previous behavior of requiring both --cert-name and
# --key-type to be set to not apply to the renew subcommand.
context.certbot(['renew', '--force-renewal', '--key-type', 'rsa'])
assert_cert_count_for_lineage(context.config_dir, certname, 3)
key3 = join(context.config_dir, 'archive', certname, 'privkey3.pem')
assert_rsa_key(key3)
context.certbot(['renew', '--force-renewal', '--key-type', 'ecdsa'])
assert_cert_count_for_lineage(context.config_dir, certname, 5)
key5 = join(context.config_dir, 'archive', certname, 'privkey5.pem')
assert 200 < os.stat(key5).st_size < 250 # ec keys of 256 bits are ~225 bytes
assert_elliptic_key(key5, SECP256R1)
def test_ocsp_must_staple(context: IntegrationTestsContext) -> None: