On Tue, 1 Apr 2025 17:29:57 GMT, Sean Mullan wrote:
> > > I am dubious that this is the right thing to do. There is a distinct
> > > difference between a certificate that is trusted and one that requires
> > > additional validation to determine if it is trusted. Blindly trusting
> > > self-sig
On Mon, 27 Jan 2025 22:43:32 GMT, Tim Jacomb wrote:
>> ## The change
>>
>> Without this change intermediate certificates that don't have explicit trust
>> settings are ignored not added to the truststore.
>>
>>
>>
>> ## Reproducer
>>
>> See https://github.com/timja/openjdk-intermediate-ca-r
On Mon, 27 Jan 2025 21:34:08 GMT, Tim Jacomb wrote:
>> ## The change
>>
>> Without this change intermediate certificates that don't have explicit trust
>> settings are ignored not added to the truststore.
>>
>>
>>
>> ## Reproducer
>>
>> See https://github.com/timja/openjdk-intermediate-ca-r
On Sun, 26 Jan 2025 22:58:04 GMT, Tim Jacomb wrote:
>> test/jdk/java/security/KeyStore/CheckMacOSKeyChainIntermediateCATrust.java
>> line 166:
>>
>>> 164: private static void assertThat(boolean expected, String message,
>>> List certificates) {
>>> 165: if (!expected) {
>>> 166:
On Sat, 25 Jan 2025 01:12:01 GMT, Alexey Bakhtin wrote:
>> Tim Jacomb has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert unneeded change
>
> test/jdk/java/security/KeyStore/CheckMacOSKeyChainInter
On Sun, 26 Jan 2025 23:04:29 GMT, Tim Jacomb wrote:
>> ## The change
>>
>> Without this change intermediate certificates that don't have explicit trust
>> settings are ignored not added to the truststore.
>>
>>
>>
>> ## Reproducer
>>
>> See https://github.com/timja/openjdk-intermediate-ca-r
On Fri, 3 Jan 2025 11:28:01 GMT, Tim Jacomb wrote:
> ## The change
>
> Without this change intermediate certificates that don't have explicit trust
> settings are ignored not added to the truststore.
>
>
>
> ## Reproducer
>
> See https://github.com/timja/openjdk-intermediate-ca-reproducer
>
On Fri, 3 Jan 2025 11:28:01 GMT, Tim Jacomb wrote:
> ## The change
>
> Without this change intermediate certificates that don't have explicit trust
> settings are ignored not added to the truststore.
>
>
>
> ## Reproducer
>
> See https://github.com/timja/openjdk-intermediate-ca-reproducer
>
On Tue, 7 Jan 2025 17:01:10 GMT, Tim Jacomb wrote:
>> ## The change
>>
>> Without this change intermediate certificates that don't have explicit trust
>> settings are ignored not added to the truststore.
>>
>>
>>
>> ## Reproducer
>>
>> See https://github.com/timja/openjdk-intermediate-ca-re
On Mon, 6 Jan 2025 21:53:34 GMT, Tim Jacomb wrote:
> Does that add value to add a test so someone could run it manually?
Yes, I think a manual test is better than nothing.
-
PR Comment: https://git.openjdk.org/jdk/pull/22911#issuecomment-2574022994
>
> Tim, any progress on the OCA?
>
> Thanks,
>
> Sean
>
> On 1/13/25 2:47 PM, Alexey Bakhtin wrote:
>> Hello Sean, Tim
>>
>> I've attached logs to the JDK-8347067, created based on Tim’s report.
>> As you mentioned already, the issue happens
On Tue, 14 Jan 2025 22:41:47 GMT, Jamil Nimeh wrote:
> This makes a small change to the default value of the
> `com.sun.security.ocsp.readtimeout` System property. When not explicitly
> specified, it will be set to the value of the `com.sun.security.ocsp.timeout`
> System property, which help
Hello Sean, Tim
I've attached logs to the JDK-8347067, created based on Tim’s report.
As you mentioned already, the issue happens because the TLS server sends
truncated chain without CA intermediate certificates.
In my understanding, it should not be a problem if the Root and CA intermediate
are
Hello Tim,
It looks like the use case you described can be easily achieved by wrapping all
certificates from the KeychainStore-ROOT and KeychainStore stores into one
custom Trust Store. As far as I know, all certificates should be in one or
another Keychain store.
Also, please look at my comme
On Fri, 22 Nov 2024 16:39:49 GMT, Sean Mullan wrote:
>> Yes, you are right, javadoc is the same. So, not entirely correct about API.
>> But the same exact place in the KeyManagerFactory is not modified. I do not
>> know the exact policy about references in the javadoc. I prefer to have a
>> ful
On Thu, 21 Nov 2024 22:45:12 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 72:
>>
>>> 70: * security property to the desired algorithm name.
>>> 71: *
>>> 72: * @see java.security.Security security properties
>>
>> it looks lik
On Thu, 21 Nov 2024 18:29:24 GMT, Sean Mullan wrote:
> Now that JEP 486 has been integrated, the `javax.net.ssl` and
> `sun.security.ssl` package implementation dependencies on
> `System.getSecurityManager`, `AccessController.doPrivileged` and
> `AccessControlContext` can be removed.
>
> Most
> Please review a proposal to verify Trust Settings for Keychain key entries.
>
> Keychain-related Jtreg tests passed.
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Add verification to the manual macos
On Fri, 28 Jun 2024 13:07:55 GMT, Weijun Wang wrote:
> Hi Alexey, sorry I'll be on vacation starting tomorrow and won't be able to
> review this in 3 weeks. At the mean time, can you try to create a test?
> Thanks.
Thank you. Will try.
-
PR Comment: https://git.openjdk.org/jdk/pu
Please review a proposal to verify Trust Settings for Keychain key entries.
Keychain-related Jtreg tests passed.
-
Commit messages:
- 8331163: Consider Trust Settings to select SSL certificate
Changes: https://git.openjdk.org/jdk/pull/19872/files
Webrev: https://webrevs.openjdk.o
On Sat, 18 Nov 2023 02:41:05 GMT, Alexey Bakhtin wrote:
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Thi
On Thu, 21 Mar 2024 15:20:39 GMT, Sean Mullan wrote:
>> Alexey Bakhtin has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request co
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has updated the pull request incrementally w
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has updated the pull request incrementally w
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has refreshed the contents of this pull req
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has updated the pull request incrementally w
On Tue, 19 Mar 2024 14:01:14 GMT, Sean Mullan wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Load root certificates from SystemRootCertificates.keychain
>
> Is it practical to add
On Mon, 18 Mar 2024 21:05:38 GMT, Weijun Wang wrote:
>> CSR is in the Proposed state now. Workflow does not allow me to Finalize it.
>
> Now that it's in Proposed state, Joe will need to move to Provisional first.
> Since it was already Provisional some time ago and you haven't really updated
>
On Mon, 18 Mar 2024 20:50:06 GMT, Weijun Wang wrote:
>> Thank you. I've updated CSR and waiting for review.
>
> I added myself as a reviewer some time ago. You can finalize it and wait for
> approval.
CSR is in the Proposed state now. Workflow does not allow me to Finalize it.
-
P
On Mon, 18 Mar 2024 14:28:02 GMT, Weijun Wang wrote:
>> Hi @wangweij ,
>> Thank you for review.
>> Unfortunately `SecTrustCopyCustomAnchorCertificates` can not be used also.
>> It is used to retrieve certificates from your own created SecTrust. As I
>> know it is not possible to create/load Se
On Fri, 8 Mar 2024 19:47:00 GMT, Weijun Wang wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Load root certificates from SystemRootCertificates.keychain
>
> src/java.bas
On Fri, 16 Feb 2024 15:01:34 GMT, Weijun Wang wrote:
>>> Will KEYCHAINSTORE-ROOT contains trusted certs inside KEYCHAINSTORE? I
>>> tried on my machine and there are some items not in `security
>>> dump-trust-settings -s`.
>> `security dump-trust-settings -s` returns only predefined root certif
On Fri, 16 Feb 2024 15:01:34 GMT, Weijun Wang wrote:
> > `security dump-trust-settings -s` returns only predefined root
> > certificates. KEYCHAINSTORE-ROOT additionally contains installed root
> > trusted certificates in the system domain
>
> Are you sure they should be added into this keysto
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has updated the pull request incrementally w
Hello Graham,
This functionality is under review now at
https://github.com/openjdk/jdk/pull/16722
This patch proposes access to the MacOS trust store using new java
KeychainStore-Root keystore.
Feel free to review and comment.
Regards
Aleksei
> On 14 Feb 2024, at 02:16, Graham Leggett wrote:
On Thu, 1 Feb 2024 21:07:32 GMT, Weijun Wang wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update CheckMacOSKeyChainTrust test
>
> test/jdk/java/security/KeyStore/CheckMacOSKeyCha
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has updated the pull request incrementally w
On Fri, 2 Feb 2024 19:37:18 GMT, Alexey Bakhtin wrote:
> Will KEYCHAINSTORE-ROOT contains trusted certs inside KEYCHAINSTORE? I tried
> on my machine and there are some items not in `security dump-trust-settings
> -s`.
`security dump-trust-settings -s` returns only predefined root cer
On Thu, 1 Feb 2024 21:36:51 GMT, Weijun Wang wrote:
> Will KEYCHAINSTORE-ROOT contains trusted certs inside KEYCHAINSTORE? I tried
> on my machine and there are some items not in `security dump-trust-settings
> -s`.
I've found an issue in the original implementation that prevents adding
diffe
On Thu, 1 Feb 2024 21:11:31 GMT, Weijun Wang wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update CheckMacOSKeyChainTrust test
>
> test/jdk/java/security/KeyStore/CheckMacOSKeyCha
On Wed, 31 Jan 2024 15:08:09 GMT, Weijun Wang wrote:
> Great! The change looks good. Can you manage to add a test? Maybe try to load
> both store types. Make sure they have different contents and not empty (?).
Thank you. I have updated `java/security/KeyStore/CheckMacOSKeyChainTrust.java`
tes
On Wed, 31 Jan 2024 15:33:28 GMT, Weijun Wang wrote:
> Do you intend to call `addIdentitiesToKeystore` for both store types?
Yes, you are right. Thank you. We do not need private identities in the root
keystore. Updated
-
PR Comment: https://git.openjdk.org/jdk/pull/16722#issuecom
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has updated the pull request incrementally w
On Wed, 24 Jan 2024 16:04:03 GMT, Weijun Wang wrote:
> Is it possible to reuse some some lines from `addCertificatesToKeystore`?
>
> BTW, I reviewed the CSR.
Hi @wangweij,
Thank you a lot for PR and CSR review. I have updated PR with review findings
and refactored addCertificatesToKeystore/add
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has updated the pull request incrementally w
On Wed, 24 Jan 2024 15:41:11 GMT, Weijun Wang wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add KeychainStore-ROOT keystore for root certificates
>
> src/java.base
On Thu, 4 Jan 2024 16:56:36 GMT, Weijun Wang wrote:
> What are the change for existing `addCertificatesToKeystore` for? Is there
> any behavior change?
Hi @wangweij . No behavior changes. Just reformatted to make it similar to
addCertificatesToKeystoreRoot. Can be reverted back.
-
On Mon, 20 Nov 2023 13:49:33 GMT, Weijun Wang wrote:
>> Please review the proposed fix.
>>
>> The patch loads system root certificates from the MacOS Keychain with
>> TrustSettings.
>> It allows to build a trusted certificate path using the MacOS Keychain store
>> only.
>
> How about putting t
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has updated the pull request incrementally w
> Please review the proposed fix.
>
> The patch loads system root certificates from the MacOS Keychain with
> TrustSettings.
> It allows to build a trusted certificate path using the MacOS Keychain store
> only.
Alexey Bakhtin has updated the pull request incrementally w
Please review the proposed fix.
The patch loads system root certificates from the MacOS Keychain with
TrustSettings.
It allows to build a trusted certificate path using the MacOS Keychain store
only.
-
Commit messages:
- 8320362: Load anchor certificates from Keychain keystore
Ch
On Thu, 24 Aug 2023 21:24:51 GMT, Alexey Bakhtin wrote:
>> JGSS is implemented in the JVM in 2 levels: the standard Java security
>> provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS
>> login module for Kerberos in com.sun.security.auth.modu
y (`“sun.security.auth.skipLogin”`)
> to set the default value if this option is not provided. This way it would
> not break the regular Java Kerberos provider and allow users to both
> individually (via JAAS configs) and globally (via the property) set the
> expected behavior
Alexe
On Fri, 11 Aug 2023 23:08:56 GMT, Alexey Bakhtin wrote:
> JGSS is implemented in the JVM in 2 levels: the standard Java security
> provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS
> login module for Kerberos in com.sun.security.auth.module.Krb5LoginModul
On Mon, 14 Aug 2023 16:28:24 GMT, Eirik Bjorsnos wrote:
>> JGSS is implemented in the JVM in 2 levels: the standard Java security
>> provider for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS
>> login module for Kerberos in com.sun.security.auth.module.Krb5LoginModule.
>> The
JGSS is implemented in the JVM in 2 levels: the standard Java security provider
for Kerberos in sun.security.jgss.krb5.Krb5MechFactory and the JAAS login
module for Kerberos in com.sun.security.auth.module.Krb5LoginModule. The
problem is that in this hierarchy, the login module doesn't go throug
On Fri, 2 Jun 2023 12:58:36 GMT, Andrew John Hughes wrote:
>> Currently, security properties are held within the `java.security` file in
>> the JDK tree for each installed JDK. The system property
>> `java.security.properties` can be used to point to a file containing
>> additional properties.
On Fri, 2 Jun 2023 00:57:49 GMT, Andrew John Hughes wrote:
> Currently, security properties are held within the `java.security` file in
> the JDK tree for each installed JDK. The system property
> `java.security.properties` can be used to point to a file containing
> additional properties. The
On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin wrote:
> This patch fixes a possible native memory leak in case of a custom native GSS
> provider.
> The actual leak was reported in production.
>
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests
>
On Tue, 14 Mar 2023 16:35:30 GMT, Daniel Fuchs wrote:
> Thanks Alexey. Tests returned green. Good to go!
Thank you a lot for review
-
PR: https://git.openjdk.org/jdk/pull/12920
On Tue, 14 Mar 2023 14:30:21 GMT, Daniel Fuchs wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More space after catch
>
> src/java.base/share/classes/sun/net/www/protocol/http/Neg
> This patch fixes a possible native memory leak in case of a custom native GSS
> provider.
> The actual leak was reported in production.
>
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests
> are passed
Alexey Bakhtin has updated the pull request
> This patch fixes a possible native memory leak in case of a custom native GSS
> provider.
> The actual leak was reported in production.
>
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests
> are passed
Alexey Bakhtin has updated the pull request
On Mon, 13 Mar 2023 16:02:10 GMT, Weijun Wang wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix formatting
>
> src/java.base/share/classes/sun/net/www/protocol/http/NegotiateA
> This patch fixes a possible native memory leak in case of a custom native GSS
> provider.
> The actual leak was reported in production.
>
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests
> are passed
Alexey Bakhtin has updated the pull request
> This patch fixes a possible native memory leak in case of a custom native GSS
> provider.
> The actual leak was reported in production.
>
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests
> are passed
Alexey Bakhtin has updated the pull request
On Fri, 10 Mar 2023 15:05:16 GMT, Weijun Wang wrote:
>> This patch fixes a possible native memory leak in case of a custom native
>> GSS provider.
>> The actual leak was reported in production.
>>
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests
>> are passed
>
>
On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin wrote:
> This patch fixes a possible native memory leak in case of a custom native GSS
> provider.
> The actual leak was reported in production.
>
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg test
On Wed, 8 Mar 2023 12:29:55 GMT, Daniel Fuchs wrote:
>> This patch fixes a possible native memory leak in case of a custom native
>> GSS provider.
>> The actual leak was reported in production.
>>
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests
>> are passed
>
>
On Wed, 8 Mar 2023 12:24:51 GMT, Daniel Fuchs wrote:
>> This patch fixes a possible native memory leak in case of a custom native
>> GSS provider.
>> The actual leak was reported in production.
>>
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests
>> are passed
>
>
On Wed, 8 Mar 2023 09:05:19 GMT, Alexey Bakhtin wrote:
> This patch fixes a possible native memory leak in case of a custom native GSS
> provider.
> The actual leak was reported in production.
>
> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg test
This patch fixes a possible native memory leak in case of a custom native GSS
provider.
The actual leak was reported in production.
sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are
passed
-
Commit messages:
- 8303809: Dispose context in SPNEGO Negoti
72 matches
Mail list logo
