Sign git commit with x509 certificate in corporate

I have learned from the documentation that it is possible to sign git tags and commits.

git config --global user.signingkey 0A46826A

Docs: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

This works for GPG. Has somebody done something like this with X509 user certificates?

It looks like GPG is not compatible or interchangeable with x509 pki certificates. Since this is in a corporate environment GPG is not a option.

It would be great if somebody could share thoughts or experiences how this could be done with x509 certs? What would be required and what it takes to implement something like this?

That should be easier with Git 2.19 (Q3 2018), since "git tag -s" etc. now have a few configuration variables (gpg.format that can be set to "openpgp" or "x509", and gpg.<format>.program that is used to specify what program to use to deal with the format) to allow x.509 certs with CMS via "gpgsm" to be used instead of openpgp via "gnupg".

See commit 53fc999 (20 Jul 2018), commit 1e7adb9, commit b02f51b, commit 42149d7, commit 58af57e, commit 57a8dd7 (17 Jul 2018), and commit 1865a64 (18 Jul 2018) by Henning Schild (henning-schild).
^{(Merged by Junio C Hamano -- gitster -- in commit 3ec5ebe, 15 Aug 2018)}

That involved changes like:

gpg-interface: add new config to select how to sign a commit

Add "gpg.format" where the user can specify which type of signature to use for commits.

gpg-interface: introduce an abstraction for multiple gpg formats

Create a struct that holds the format details for the supported formats.
This commit prepares for the introduction of more formats, that might use other programs and match other signatures.

gpg-interface: do not hardcode the key string len anymore

gnupg does print the keyid followed by a space and the signer comes next. The same pattern is also used in gpgsm, but there the key length would be 40 instead of 16.

Instead of hardcoding the expected length, find the first space and calculate it.
Input that does not match the expected format will be ignored now, before we jumped to found+17 which might have been behind the end of an unexpected string.