pavlo-v-chernykh / keystore-go Goto Github PK

When building for a x86 architecture the math.MaxUint32 will overflow int since MaxUint32 is not type declared it will be set to int. If you don't want to support a x86 architecture you can close this.

For some reason I am getting Unrecognized keystore format when using keytool with a keystore built with this library.

Is this library expected to be compatible with keytool ?

I am trying to decode one of my jks file, and when running the code, i am getting the below error.

2020/08/25 15:28:58 read 1 entry: read private key entry: decrypt content: got invalid digest```

I am sure i am passing the right credentials, as i am able to decode using the keytool on command line.
I see this issue is fixed, but seems its repeating.  Any help?

Hi. Is it possible to have multiple certs in TrustedCertificateEntry. We have PEM cert containing multiple certs

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/sun/security/provider/JavaKeyStore.java?av=f#473

It's useful to replace the keytool command when we don't want to install JDK in the server.

Hi,

while I incorporated your great lib into my app, I figured out that Oracle changed the default JKS format to PKCS12 *1.
I stumbled upon this issue because I got the error "magic bytes are wrong".
While I quickly verified my installed JDKs ... it seems that Temurin picked up this change later, with v20.
Without further analysis, I do assume the various JDKs/JREs do use one or the other format.

Since I assume also other users of your great lib will sooner or later face this issue,
I wonder if you would be interested in extending your lib to support this PKCS12 format?
Or - in case I would provide a PR - would you consider merging it?

*1) See Consolidated JDK 9 Release Notes - Change in the default keystore type to PKCS12

Regards
Martin

keystore.New()

It is a convenient way of initializing, but is there a way to configure for a PKCS#12 based Keystore? Or may be to convert without utilizing another lib/utility to do the same. #

The sampel keystore in your repository does not produce this problem
i.e. the one here https://github.com/pavel-v-chernykh/keystore-go/blob/41c45484322d62c5a15736e40282d88ec4f37012/testdata/keystore.jks

However if I were to do this

keytool -genkey -alias skipper -keyalg RSA -keystore skipper.keystore -validity 30 -storetype JKS -dname "CN=localhost" -keypass skipper -storepass skipper

and attempt to load it like this

func TestKeyStoreRoundTrip(t *testing.T) {
	testCases := []struct {
		name    string
		passwod []byte
		alias   string
		outname string
	}{
		{
			`./skipper.keystore`,
			[]byte("password"),
			"skipper",
			`./skipperout.keystore`,
		},
		{
			`/home/janitha/go/src/github.com/keystore-go/testdata/keystore.jks`,
			[]byte("password"),
			"alias",
			`./samplekeystore.jks`,
		},
	}
	for i, tc := range testCases[0:] {
		t.Run(strconv.Itoa(i), func(t *testing.T) {
			fr, err := os.Open(tc.name)
			if err != nil {
				t.Fatal(err)
			}
			defer func() {
				if err := fr.Close(); err != nil {
					t.Fatal(err)
				}
			}()
			ks := keystore.New()
			pwd := tc.passwod
			if err := ks.Load(fr, pwd); err != nil {
				t.Fatal(err)
			}
		})
	}
}

The digests are as follows

computedDigest:  cd314e68e349ec8ac3a4496335b26c85ce6a97f5
actualdigest: e4059bc66cc398dcf4b2878bd9b0409949457d2e

The above gives got invalid digest from this line https://github.com/pavel-v-chernykh/keystore-go/blob/d66cbc26e181292e9725c0220796b3a682cafdcd/keystore.go#L186

computedDigest: 43496b66608aec887f74ca7cd6daa53887f47468
actualDigest: 43496b66608aec887f74ca7cd6daa53887f47468

The line below reads 20 bytes back into ksd.b which is then returned. This does not look like a sha1, but it works for your keystore sample

actualDigest, err := ksd.readBytes(uint32(ksd.md.Size()))

Hi @pavlo-v-chernykh !

First of all, thank you for cutting a new tag in response to #41! We've been pretty happy using your library in https://github.com/cert-manager/cert-manager, and it handles the problem of writing JKS files well for us.

I just wanted to follow up on what led to #41 being raised. It looks like the published tag for v4.4.0 was modified after it was pushed. For comparison, I downloaded the module from the official GOPROXY (https://proxy.golang.org/) and then downloaded 4.4.1 (which now points to the same commit as 4.4.0), and I saw they were different. I detailed that in this comment.

That to me means that the GOPROXY observed the old version at tag 4.4.0 and cached it, and then the tag was changed afterwards.

In turn, this means that the GOSUMDB (https://sum.golang.org/) will always fail to validate 4.4.0. Instructions to reproduce this are provided in this comment.

My question is: Do you know what happened here to cause this? I totally understand if it was an honest mistake - these things happen! I'm asking because these kinds of tag changes are really destructive for any project which depends on yours, because it means our old versions will no longer build unless checksum validation is disabled (which as a security project we're not going to do, for obvious reasons!).

I'm not sure what happened, but it's now impossible to add this module as a dependency to other projects because of a checksum mismatch.

$ go get github.com/pavlo-v-chernykh/keystore-go/[email protected]

go: downloading github.com/pavlo-v-chernykh/keystore-go/v4 v4.4.0
go: github.com/pavlo-v-chernykh/keystore-go/[email protected]: verifying module: checksum mismatch
        downloaded: h1:fBO1dUIpQgrrZ7gXJsvDhpNYsfxCuPr6NNtGHiv8FYo=
        sum.golang.org: h1:y9azNmMzvkNBPyczpNRwaV4bm0U6e7Oyrj7gi2/SNFI=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

Maybe I'm missing something? I have seen this happening in other projects when the git history got rewritten after a tag was already published.

I believe cutting a new tag will solve this, although I'm not sure if we also need a new commit, given that v4.4.0 is already pointing to the last commit.

How to reproduce:

mkdir test-keystore-dep
cd test-keystore-dep
go mod init test-keystore-dep
go get github.com/pavlo-v-chernykh/keystore-go/[email protected]

Thanks a lot! 🙂

Does this library have the ability to decrypt a private key entry? I haven't found nor examples and docs about it.

There are existing jks files which java spring application is using it.

I am trying to use keystore-go to read the same jks files directly in my own golang application for supporting https.

Wondering how to do so instead of exporting cert and key files with keytool?

app.ListenTLS(":443", "./cert.pem", "./cert.key");  // https://docs.gofiber.io/api/app#listentls

Creating multiple key stores with the same content generates different binary representations, this is true even when setting the creation timestamp at the same time in each of them. I am not sure why, but perhaps is that sha1.new() that is time dependent.
In order to implement some sort of idempotency in my automation, I need to know if two KeyStores are equivalent. or alternatively if a set of pem-formatted certs is equivalent to a KeyStore previously created.
What is the recommended approach to solve thyis issue?
Can a compare function be added to the KeyStore structure?

I will provide examples attached to this issue, so everyone can reproduce. (ALWAYS remove the tailing .txt from all files you download!)

Just like you have seen in my previous threat #44 I loop through the JKS and extract all the entries.

But as a JKS is just a collection of CA-Certs, Certs and Keys it can contain them in nearly all orders and in mostly all combinations.
I think I just catched another combination, that is not handelable with this package currently.

What did I do?

1. download the current Cert-Chain from www.google.de: www.google.de.pem.txt
2. convert it to a default JKS, without the chain, but all Certs as seperate entries:
   www.google.de.jks.txt
   this is the structure of the file:

• CA-CERT
• CERT
• CERT

3. try to loop though the JKS with this package and print out, as what which alias/entry was detected.
4. you will just get the CA-Cert entry, as there is no isCertEntry function is missing.

So this request basically asks for the extension of this package so even entries which are plain Certs, (or Cert-Chains!) can be detected.
All those entries are passwordless and shall not be able to take a password, as Certs (and Cert-Chains) are public.

Thanks in advance, I hope I could explain it good enough, so it is understandable :)

I am open for discussion and also open for providing more, if there is a need.

P.S.: please always remove the .txt file-extension from all files you download here, as they are not TXTs, but otherwise I can not upload the, as .pem & .jks are not supported by GitHub.

Great library btw - thanks for creating it!

Tried out the keystore produced in pem example & can't recover the private key:

Exception in thread "main" java.security.UnrecoverableKeyException: version mismatch: (supported:     00, parsed:     01
  at sun.security.provider.KeyProtector.recover(KeyProtector.java:338)
  at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:146)
  at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:56)
  at sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
  at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:70)
  at java.security.KeyStore.getKey(KeyStore.java:1023)
  at sun.security.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:133)
  at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
  at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
  at Server.main(Server.java:27)

Trying to create a key manager throws this exception when referencing the keystore that the example produces, example code:

KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
kmf.init(keystore, keypass);

Any ideas?

Hi, Is there any reason to use sha1 instead of sha256?, actually the keytools works with SHA-256

Looking at https://github.com/pavel-v-chernykh/keystore-go/tree/master/examples/pem
can you show an example for creating a truststore? if I have the ca.crt certificate file in pem format, is it similar to doing creating a key store but avoid ignore the private key setting?

The Private-Key entry typically consists of two sections:

1. Key
2. Cert-chain

The cert chain is publicly available, and you can use the KeyStore Explorer (on Windows) to read ALL Certificates from a JKS without needing the password. Just utilize an empty password; it will consistently work to display the certs.

The function GetTrustedCertificateEntry does not operates without requiring a password. When attempting to retrieve a cert-chain from a PrivateKeyEntry, it won't function without the correct password - even though it theoretically should. The only secured aspect of the PrivateKeyEntry is the key itself. Usually, a password isn't necessary for the public certificate.

However, in my experience, this tool has been unable to obtain public certs from a PrivateKeyEntry without the password. KeyStore Explorer, on the other hand, was able to do so without a password.

Am I doing something incorrectly, or is this tool not intended to extract public certs from a PrivateKeyEntry without a password? If it isn't, are there any plans to add this capability?

I reviewed:

https://github.com/pavlo-v-chernykh/keystore-go/blob/master/keystore.go

Here's an abbreviated version of my code:

for _, alias := range ks.Aliases() {

	if ks.IsPrivateKeyEntry(alias) {

		privateKeyEntry, err := ks.GetPrivateKeyEntry(alias, passwort)

		if err != nil {

			###ERROR-HANDLING###

		} else {

			pkPEMBlock := &pem.Block{Type: "PRIVATE KEY", Bytes: privateKeyEntry.PrivateKey}
			pkFilename := fmt.Sprintf("%s.KEY.pem", alias)

		}

		for i, cert := range privateKeyEntry.CertificateChain {

			certPEMBlock := &pem.Block{Type: "CERTIFICATE", Bytes: cert.Content}
			var certFilename string

			if i == 0 {

				certFilename = fmt.Sprintf("%s.cert.pem", strings.TrimSpace(alias))

			} else {

				certFilename = fmt.Sprintf("%s.cert-CHAIN_%d.pem", strings.TrimSpace(alias), i+1)

			}

		}

	} else if ks.IsTrustedCertificateEntry(alias) {

		trustedCertEntry, err := ks.GetTrustedCertificateEntry(alias)

		if err != nil {

			###ERROR-HANDLING###
			continue

		}

		certPEMBlock := &pem.Block{Type: "CERTIFICATE", Bytes: trustedCertEntry.Certificate.Content}
		certFilename := fmt.Sprintf("%s.cert-CA.pem", strings.TrimSpace(alias))

	}
}

Ideally, I'd like an option to accomplish this:

If an alias is ks.IsPrivateKeyEntry(alias), then when the password fails and I can't retrieve the private key, I would like to obtain the cert using the following approach:

if ks.IsPrivateKeyWithCertEntry(alias) {
    cert := ks.GetPrivateKeyCertEntry(alias)
}

This would not require a password.

Thank you in advance!

P.S.: My goal is to extract as much as possible from the JKS. I intend to convert each entry into a PEM and consolidate them into a ZIP file. Essentially, the JKS container would become a ZIP containing everything that can be extracted.

Implement integrity check as part of decoder.

As specified in java implementation

/*
 * If a password has been provided, we check the keyed digest
 * at the end. If this check fails, the store has been tampered
 * with
 */

how to get public key, here is my example, does the public key right?

ks := readKeyStore("/Users/qq/merchant_keystore.jks", []byte("123456"))
privateKeyEntey, err := ks.GetPrivateKeyEntry("merchant_key_pair", []byte("changeit"))
assert.NoError(t, err)
privateKeyEntry, err := x509.ParsePKCS8PrivateKey(privateKeyEntey.PrivateKey)
privateKey := privateKeyEntry.(*rsa.PrivateKey)
kkPublicKey, err := x509.ParsePKCS1PublicKey(privateKeyEntey.CertificateChain[0].Content)
assert.NoError(t, err)
publicKey := privateKey.PublicKey

First of all: hi, thanks for the library! We use it in cert-manager and it's great 😁

In #20 a minPasswordLen constant was added, and we've bumped on this when upgrading from v2.1 to v4.1 in our latest release. Obviously, the major version number on this library changed and so breaking changes are totally reasonable!

That said, would you consider removing the minPasswordLen or making it publicly exported or otherwise configurable? We don't really want to add a breaking change to cert-manager, and we don't want to fork this library either if we can avoid that, but we do want to upgrade to the latest version of this library to get the other changes which have been introduced since v2.

Given the serious issues with Java keystore passwords when it comes to security, I'm personally of a mind that it doesn't much matter what length the password is since it's not going to be particularly secure in any case. I've often seen these passwords be set to changeme or password across a whole organisation anyway since the passwords are usually nothing more than a false sense of security and only kept for backwards compatibility reasons.

(In addition, while I agree that encouraging good password practices is valuable, as a dev I'd rather have control of this in my app and not have it managed by the library)

If you'd accept this kind of change I'd be happy to send a PR! Please let me know what you think 😁

So using this library I wrote a method

func GenerateKeyStoreFromPem(alias string, password string, permCert []byte, pemKeyKey []byte) ([]byte, error) {
	var chain []keystore.Certificate

	// decode the certificates
	for {
		blockCert, rest := pem.Decode(pemCert)
		if blockCert == nil {
			return nil, errors.New("The supplied Pem certificate could not be decoded")
		}

		chain = append(chain, keystore.Certificate{
			Type:    "X509",
			Content: blockCert.Bytes.,
		})

		// there typically more than one certificate
		if len(rest) > 0 {
			pemCert = rest
		} else {
			break
		}
	}


	blockKey, _ := pem.Decode(pemKey)
	if blockKey == nil {
		return nil, errors.New("The supplied Pem certificate key could not be decoded")
	}

	keyStore := keystore.KeyStore{
		alias: &keystore.PrivateKeyEntry{
			Entry: keystore.Entry{
				CreationDate: time.Now(),
			},
			PrivKey:   blockKey.Bytes,
			CertChain: chain,
		},
	}

	var b bytes.Buffer
	err = keystore.Encode(&b, keyStore, []byte(password))
	if err != nil {
		log.Error("Error encrypting and signing keystore. ", err)
		return nil, err
	}
	return b.Bytes(), nil
}

but once I write to a file, and tried to open with java keytool, then I see a warning saying
Warning: The JKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12".

I guess I need to write the key in pcks12 format, is there any way to do that, is that not matter? I think it is PKCS1 based.

Java 18 migrates the cacerts keystore from JKS to a password-less PKCS12 format file. See the release notes and bug details.

When the Load method is called with the new cacerts file, this error is thrown.

Is it possible to add support for this new Java 18 format?

Done this:

git clone https://github.com/pavel-v-chernykh/keystore-go.git
cd keystore-go 
make

get this:

~/.../ExperiementalCryptoStuff/keystore-go >>> make                                                                                                              
go fmt github.com/pavel-v-chernykh/keystore-go/v4/...
golangci-lint run -c .golangci.yaml
decoder_test.go:139:6: variable name 'tt' is too short for the scope of its usage (varnamelen)
        for _, tt := range table {
            ^
decoder_test.go:358:6: variable name 'tt' is too short for the scope of its usage (varnamelen)
        for _, tt := range table {
            ^
keystore.go:295:2: variable name 'as' is too short for the scope of its usage (varnamelen)
        as := make([]string, 0, len(ks.m))
        ^
keyprotector.go:120:6: variable name 'i' is too short for the scope of its usage (varnamelen)
        for i, xorOffset := 0, 0; i < numRounds; i++ {
            ^
keystore_test.go:240:2: variable name 'f' is too short for the scope of its usage (varnamelen)
        f, err := os.Open("./testdata/keystore_keypass.jks")
        ^
keystore_test.go:15:2: variable name 'ks' is too short for the scope of its usage (varnamelen)
        ks := New()
        ^
keystore_test.go:186:2: variable name 'f' is too short for the scope of its usage (varnamelen)
        f, err := os.Open("./testdata/keystore.jks")
        ^
decoder_test.go:65:6: variable name 'tt' is too short for the scope of its usage (varnamelen)
        for _, tt := range table {
            ^
keystore.go:226:2: variable name 'ok' is too short for the scope of its usage (varnamelen)
        e, ok := ks.m[ks.convertAlias(alias)]
        ^
keyprotector.go:99:2: variable name 'md' is too short for the scope of its usage (varnamelen)
        md := sha1.New()
        ^
decoder_test.go:218:3: variable name 'd' is too short for the scope of its usage (varnamelen)
                d := decoder{
                ^
decoder_test.go:289:3: variable name 'd' is too short for the scope of its usage (varnamelen)
                d := decoder{
                ^
keystore_test.go:137:2: variable name 'ks' is too short for the scope of its usage (varnamelen)
        ks := New()
        ^
keystore.go:267:2: variable name 'ok' is too short for the scope of its usage (varnamelen)
        e, ok := ks.m[ks.convertAlias(alias)]
        ^
decoder_test.go:66:3: variable name 'd' is too short for the scope of its usage (varnamelen)
                d := decoder{
                ^
keystore.go:73:2: variable name 'ks' is too short for the scope of its usage (varnamelen)
        ks := KeyStore{m: make(map[string]interface{})}
        ^
keyprotector.go:59:6: variable name 'i' is too short for the scope of its usage (varnamelen)
        for i, xorOffset := 0, 0; i < numRounds; i++ {
            ^
keystore_test.go:295:2: variable name 'b' is too short for the scope of its usage (varnamelen)
        b, _ := pem.Decode(pkPEM)
        ^
keyprotector.go:38:2: variable name 'md' is too short for the scope of its usage (varnamelen)
        md := sha1.New()
        ^
keystore_test.go:315:2: variable name 'b' is too short for the scope of its usage (varnamelen)
        b, _ := pem.Decode(pkPEM)
        ^
keystore.go:89:2: variable name 'e' is too short for the scope of its usage (varnamelen)
        e := encoder{
        ^
keystore.go:84:26: parameter name 'w' is too short for the scope of its usage (varnamelen)
func (ks KeyStore) Store(w io.Writer, password []byte) error {
                         ^
make: *** [Makefile:7: lint] Fehler 1
~/.../ExperiementalCryptoStuff/keystore-go >>> 

What's wrong...???

I am on this:

~/.../ExperiementalCryptoStuff/keystore-go >>> go version                                                                                                        
go version go1.17.1 linux/amd64
~/.../ExperiementalCryptoStuff/keystore-go >>> golangci-lint version                                                                                             
golangci-lint has version 1.43.0 built from 861262b7 on 2021-11-03T11:57:46Z
~/.../ExperiementalCryptoStuff/keystore-go >>> uname -a                                                                                                          
Linux un-tuxedo 5.13.19-2-MANJARO #1 SMP PREEMPT Sun Sep 19 21:31:53 UTC 2021 x86_64 GNU/Linux
~/.../ExperiementalCryptoStuff/keystore-go >>> 

One month ago, you commited decoder.go and moved computedDigest := ksd.md.Sum(nil) in Decode function to after actualDigest, err := ksd.readBytes(uint32(ksd.md.Size()))
The Decode function returns "got invalid digest" error every time after that.
The reason of error is containing digest at last of file for calculating digest.
Please re-check it.
Thank you.

Background

The github.com/pavel-v-chernykh/keystore-go uses Go modules and the current release version is v3. And it’s module path is "github.com/pavel-v-chernykh/keystore-go", instead of "github.com/pavel-v-chernykh/keystore-go/v3". It must comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:

A package that has opted in to modules must include the major version in the import path to import any v2+ modules
To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2.
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Steps to Reproduce

GO111MODULE=on, run go get targeting any version >= v3.0.0 of the pavel-v-chernykh/keystore-go:

$ go get github.com/pavel-v-chernykh/[email protected]
go: finding github.com/pavel-v-chernykh/keystore-go v3.0.0
go: finding github.com/pavel-v-chernykh/keystore-go v3.0.0
go get github.com/pavel-v-chernykh/[email protected]: github.com/pavel-v-chernykh/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v3

run go get github.com/pavel-v-chernykh/keystore-go, the version will stuck in v2.1.0:

$go get github.com/pavel-v-chernykh/keystore-go
go: downloading github.com/pavel-v-chernykh/keystore-go v1.0.0
go: downloading github.com/pavel-v-chernykh/keystore-go v2.1.0+incompatible
go: github.com/pavel-v-chernykh/keystore-go upgrade => v2.1.0+incompatible

SO anyone using Go modules will not be able to easily use any newer version of pavel-v-chernykh/keystore-go.

Solution

1. Fix module path to strictly follow SIV rules.

Patch the go.mod file to declare the module path as github.com/pavel-v-chernykh/keystore-go/v3 as per the specs. And adjust all internal imports.
The downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide,govendor…).

If you don't want to break the above repos. This method can provides better backwards-compatibility.
Release a v2 or higher module through the major subdirectory strategy: Create a new v3 subdirectory (github.com/pavel-v-chernykh/keystore-go/v3) and place a new go.mod file in that subdirectory. The module path must end with /v3. Copy or move the code into the v3 subdirectory. Update import statements within the module to also use /v3 (import "github.com/pavel-v-chernykh/keystore-go/v3/…"). Tag the release with v3.x.y.

2. Kill the go.mod files, rolling back to GOPATH.

This would push them back to not being managed by Go modules (instead of incorrectly using Go modules).
Ensure compatibility for downstream module-aware projects and module-unaware projects projects

3. Suggest your downstream module users use hash instead of a version tag.

If the standard rule of go modules conflicts with your development mode. Or not intended to be used as a library and does not make any guarantees about the API. So you can’t comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation.
Regardless, since it's against one of the design choices of Go, it'll be a bit of a hack. Instead of go get github.com/pavel-v-chernykh/keystore-go@version-tag, module users need to use this following way to get the pavel-v-chernykh/keystore-go:
(1) Search for the tag you want (in browser)
(2) Get the commit hash for the tag you want
(3) Run go get github.com/pavel-v-chernykh/keystore-go@commit-hash
(4) Edit the go.mod file to put a comment about which version you actually used
This will make it difficult for module users to get and upgrade pavel-v-chernykh/keystore-go.

[*] You can see who will be affected here: [26 module users, e.g., paketo-buildpacks/graalvm, paketo-buildpacks/libjvm, banzaicloud/kafka-operator]
https://github.com/search?p=2&q=pavel-v-chernykh%2Fkeystore-go+filename%3Ago.mod&type=Code

Summary

You can make a choice to fix DM issues by balancing your own development schedules/mode against the affects on the downstream projects.

For this issue, Solution 1 can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.

References

• https://github.com/golang/go/wiki/Modules#semantic-import-versioning
• https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning
• https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

We are trying to store pfx format(encoded with PKCS12 format) TrustedEntry in keystore. We are using following way:

te := keystore.TrustedCertificateEntry{
		CreationTime: time.Now(),
		Certificate: keystore.Certificate{
			Content: pfxData,
			Type: "pkcs12",
		},
	}

Looking at test examples, it sounds like we can only pass X509 certs. Any suggestions?

I tried set CreationDate to time.Now() for PrivateKeyEntry,
and use cert.NotBefore for trustedCertEntry.

keytool -list -keystore mykeystore.jks -storepass asdfasdf

Keystore type: JKS
Keystore provider: SUN
　
Your keystore contains 3 entries
　
xxx-ca, Jan 16, 1970, trustedCertEntry,
Certificate fingerprint (SHA-256): DA:2A:BE:92:25:D7:95:A3:80:E2:89:9D:53:0E
yyy-ca, Jan 18, 1970, trustedCertEntry,
Certificate fingerprint (SHA-256): B8:14:1F:4A:8B:93:4A:E5:8C:01:06:49:4A:9D
mycert, Jan 18, 1970, PrivateKeyEntry,
Certificate fingerprint (SHA-256): 6C:06:2F:0D:64:C7:7C:25:48:C4:69:71:6D:85

also i tried export the certificate from keystore, and check the date, it's correct.

keytool -exportcert -file myks.crt -alias mycert -storepass asdfasdf -keystore mykeystore.jks -rfc
openssl x509 -noout -text -in myks.crt

......
Validity
Not Before: Sep 15 17:30:21 2017 GMT
Not After : Sep 13 17:30:21 2027 GMT
......

please help check the issue, thanks.

Is the project FIPS 140-2/3 compliant?

I have seen places where the code use SHA1 #28 and it seems to be an disallowed algorithm according to https://crypto.stackexchange.com/questions/35743/where-in-the-fips-documents-is-it-stated-that-sha-1-is-not-secure

Can you please provide insight? Thanks.

Hello.
I'm using a pre-existent JKS file, used in a Java application, to get read by a go application.
This JKS keystore doesn't have a password. I can read it using keytool:

*****************  WARNING WARNING WARNING  *****************
* L'intégrité des informations stockées dans votre fichier de clés  *
* n'a PAS été vérifiée. Pour cela, *
* vous devez fournir le mot de passe de votre fichier de clés.                  *
*****************  WARNING WARNING WARNING  *****************

Type de fichier de clés : jks
Fournisseur de fichier de clés : SUN

Votre fichier de clés d'accès contient 1 entrée

Nom d'alias : test
Date de création : 6 août 2021
Type d'entrée : PrivateKeyEntry
...

When I try to read it using the lib, I got the "got invalid digest" error.

f, err := os.Open(conf.KeystorePath)
	if err != nil {
		return nil, err
	}

	defer func() {
		if err := f.Close(); err != nil {
			panic(err)
		}
	}()

	ks := keystoregov4.New()
	if err := ks.Load(f, pass); err != nil { //got invalid digest here
		return nil, err
	}
}

I've tried with pass = nil and with pass being a 0 byte array.