Hello,
I have been able to set-up a Windows 2019 Domain, so I did some testing with
simple and disgest-MD5. As expected both will be rejected when the
integritylevel=2 is set.
For Digest-md5 it is enough to request Auth-int with AD to get over this check
(funny enough it seems to not sign requ
On Thu, Dec 19, 2019 at 11:09 AM Severin Gehwolf wrote:
>
> Hi Volker,
>
> On Wed, 2019-12-18 at 22:27 +0100, Volker Simonis wrote:
> > Hi Severin,
> >
> > not strictly a 8u "Reviewer" yet, but I've looked at your changes
> > (this one and 8232019) nevertheless :)
>
> Thanks for the review!
>
> >
I uploaded a less disruptive webrev at
https://cr.openjdk.java.net/~weijun/8236470/webrev.01.
--Max
> On Dec 21, 2019, at 7:47 PM, Weijun Wang wrote:
>
> Oh, I take back the "mutates the internal" words, it didn't. algName is only
> a local variable.
>
> So the major problem of the current c
Hi,
I would like to downport this for parity with 11.0.7-Oracle.
It does not apply clean because in 11 changes were applied in
a different order than in 14.
http://cr.openjdk.java.net/~goetz/wr19/8213010-certmgr.exe_keys-jdk11/
In ECUtil.java I had to resolve the Copyright.
patching file src
Oh, I take back the "mutates the internal" words, it didn't. algName is only a
local variable.
So the major problem of the current code is that while getName() is modified to
return the "full" signature algorithm name, getEncodedParams() still returns it.
I realized my fix does have the problem
Please take a review at
http://cr.openjdk.java.net/~weijun/8236470/webrev.00/
The current implementation is not good at dealing with ECDSA specified by
ecdsa-with-SHA2 plus a hash algorithm. While the AlgorithmId::getName is able
to return the "full" signature algorithm name, it mutates the
