Non-RSA certificates are currently not supported about clone-cert

[rdebath]

Two annoyances:

• -newkey param:file.crt is a bit broken for RSA keys
• -days only works for whole days

Otherwise, you can make a matching, self-consistent, self-signed certificate without hacking up hexdumps.

BTW: Self-signed certificates are perfectly fine for providing security. BUT they provide no TRUST, the only "trustworthiness" they can have is ... checking the fingerprint.

#!/bin/sh -

HOST="$1"

:|openssl s_client -connect "$HOST":443 > x_clone_in.crt

KEYTYPE=param:x_clone_in.crt
RSABITS=$(openssl x509 -text -noout -in x_clone_in.crt 2>&1 |
            awk '/Public-Key: .*bit/{gsub("[^0-9]","",$2); print $2;}')
[ "$RSABITS" != "" ] && KEYTYPE=rsa:$RSABITS

openssl req -newkey $KEYTYPE -subj / -keyout x_clone.key -nodes > /dev/null

STRDAY="$(date +%s --date="$(openssl x509 -noout -startdate -in x_clone_in.crt | sed 's/^[^=]*=//')" ||:)"
ENDDAY="$(date +%s --date="$(openssl x509 -noout -enddate -in x_clone_in.crt | sed 's/^[^=]*=//')" ||:)"
DAYS=$(( ENDDAY/86400 - STRDAY/86400 ))

faketime @$STRDAY openssl x509 -days $DAYS -in x_clone_in.crt -signkey x_clone.key > x_clone.crt

[AdrianVollmer]

Thanks, I didn't know you can sign entire certificates this way!

It has another downside, though: The certificate becomes self-signed. I agree that the way it is now is quite hackish, but it allows you to clone non-self-signed certs as well.

And of course you're correct regarding the trust. I guess to be precise, they provide integrity and confidentiality but no authenticity.

[rdebath]

The openssl x509 command does the same keep all the extensions trick if you feed the -CA option with a self-signed certificate (which you just made with -signkey). Making a self-signed certificate to sign it with containing the correct issuer looks like a bit more of a pain but openssl x509 -noout -issuer -nameopt multiline seems to create a list that's mostly compatible with the req format config file so it should all work.

Also I just noticed it always uses the default hash for signing, so that would need to be adjusted too, along with what to do when the key type used for signing is different to the the type of the key that's being signed.

... Ah yes "integrity", "confidentiality" and "authentication" ... Actually, we might be wrong there; RSA can do encryption, unlike DSA and ECDSA, but isn't the current connection style to use ECDHE to do the key exchange that provides the first two properties? The RSA/DSA/ECDSA only ensures that we're doing the ECDHE with the right person, ie "authentication" ? 😕

[AdrianVollmer]

I'm going to have to look into this more closely when I have some free time. Thanks for the help though!