cvs update -dP
Document update suggestion.
Keeping in mind the documents are implied as step by step instructions.
The instruction |cvs update -dP could get complicated for some
developers due to
|
|missing perquisites steps on page
http://tomcat.apache.org/tomcat-9.0-doc/appdev/source.html|
|The two steps I can remember I did at the time was to create a
directory "CVSROOT" at ~/cvs/CVSROOT
|
|then point to that directory as the "cvs application" home directory
with the command|
||
|$ *cvs -d /nfs/roc/home/cvs command*|
||
|I actually went to this page
https://www.eoas.ubc.ca/research/moc2/cvstutorial/setting.html
|
|to complete the setup because your documents are incomplete.|
|
|
|I also think I had a smoother ride of the setup because I was using a
*.nix {ubuntu} so the VI/VIM editors,|
|which are built in the Operating System launch automatically without
issue with cvs.
|
|I also noticed on another mailing list some people, who even work as a
pair still couldn't get "up and running"
|
|with the supplied maven archetype examples. Due to the fact mvn command
line |||argument(s) { javafx:run || jetty:run ] |was not mentioned .|
|In this case javafx:run need to be set as goals for this particular
IDE. Due to missing setup instruction(s) the time and effort of
archetype can go to waste. These minor missing instructions can be a
major headache in getting a potential developer "up and running".|
|This "up and running" is not just a step but an important *milestone*
especially For experienced developers. This is because after that the
experience developers know from this point on they have taken over
control of the software behaviour.
|
b/r
Zahid
www.backbutton.co.uk
¯\_(ツ)_/¯
I ♡۶ Lynx text browser
recover crashed ms-word .doc with ms-debug.
use file header with filename.
Re: Let's Encrypt with Tomcat?
Am I to understand that Tomcat 8.5.40 can use the ".cer," ".ca.crt" and ".key" files directly, instead of the Java Keystore file? On 12/30/19 1:41 PM, Peter Kreuser wrote: Correct! Great. Then if I can figure out how to get this thing I'm studying the server under discussion, and I can't figure out what I did, some six months ago, to make Tomcat look like 443 to the outside world. Here is what I do know: * It's an AWS EC2 instance. * There is no load balancer involved. * The only active connector in server.xml has it listening on 8443, with a proxyPort clause specifying 443. * If I do a netstat, I find that something is indeed listening on 8443, but nothing is listening on 443. * If I look at the AWS console, if there is something translating 443 to 8443, I can't find it. * If I do an "iptables -L," I get only column headings. * There are evidently two copies of Apache httpd on the box, one of which evidently came with the OS, and the other of which evidently came with the Bitnami SVN/Trac stack. Only the latter copy is active. It is listening on ports 81 (unsecured, but blocked by the firewall) and 8000 (secured). * If I open port 81 up to my own IP (in the AWS firewall), I can reach the same SVN/Trac landing page on unsecured port 81 that I can on secured port 8000. * Tomcat is running completely independently of the active httpd: if I shut down the active httpd, Tomcat still responds. * I was able to find the apache VirtualHost configurations (in a file called bitnami.conf, naturally), and by replacing the one for port 81 with (and once again, domain names have been changed to protect the innocent): ServerName foo.bar.net Redirect permanent / https://foo.bar.net:8000/ the unsecured Port 81 now redirects to 80. Conversely, if I leave out the :8000 it redirects to the Tomcat server. * Like a complete and utter idiot, I left no notes whatsoever about how I set this thing up in the first place. Probably because I didn't fully understand what I'd done, or how. * Just as it was when I *was* setting this thing up in the first place, httpd configuration files (that can be all over the place) make me long for the simplicity of Tomcat configuration files. I *think* I can *probably* get Apache (and a cron job running certbot) on Let's Encrypt, and Tomcat using its certs (and a cron job reloading them), without understanding what I'd done to get Tomcat showing up on 443 to the outside world, but it would be nice if I *did* understand what I'd done. -- James H. H. Lampert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ECDSA Private Keys
> Am 02.01.2020 um 17:13 schrieb Christopher Schultz > : > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Peter, > > On 1/2/20 04:24, logo wrote: > >> There may be an issue with the provided/available ciphers! >> >> The connector comes up correctly, is accessible through the browser >> but if I test the ssl setup, I get an error message that the >> key/cert may not be used for "Key agreement" >> >> See: testssl.sh :8443 >> >> Signature Algorithm ECDSA with SHA256 Server key size >> EC 256 bits Server key usage Digital Signature, Key >> Encipherment Certificate incorrectly used for key agreement Server >> extended key usageTLS Web Server Authentication, TLS Web Client >> Authentication >> >> I cannot find the reason for that yet, testssl complains if there >> are TLS_ECDH_*-ciphers with the wrong server key usage. The setup >> may be causing troubles in testssl.sh as Tomcat provides ciphers >> that maybe should not be available with ECDSA certs (? _RSA??? >> Maybe even ECDH_ECDSA???)? >> >> Testing 370 ciphers via OpenSSL plus sockets against the server, >> ordered by encryption strength >> >> Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption >> Bits Cipher Suite Name (IANA/RFC) >> -- > - --- >> >> >> >> There is probably more complexity to implementation of ECDSA in >> Tomcat with JSSE?!? > > I seem to remember a bug where Tomcat does not check the "usage" of a > key before trying to use it. I couldn't find it in BZ, maybe it was > fixed in some partial way. > > What do those lists represent? All the cipher suites tried, or all > that connected successfully? > testssl.sh [1] tries a list of 370 ciphers. Apparently those are the successful socket connects. [1] https://github.com/drwetter/testssl.sh Peter > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4OFroACgkQHPApP6U8 > pFifJw//befvNHGem8GtKH5ds3bEdZk/nvxi1FsytOMA7YplenYI7LxnPrHYeQj0 > L6jUxgYJk5canTmCi/Zw2st03wCAXCfO+AHUYDu4TwA+Ml7ij+cmwtt5Di9onhg0 > c23bDS8WNkiTA6aW4dX5RgPj7+C60k8he+uLCpeoDjWh6b778IR7UcRdd+9uFdVU > wx4ILhl1MNnbQeyH6UMolQA4ms+4HG09mDYcQwK4B5VejQnbtzud1hkB0mJJCCes > MbSaE/6BA4cs9feHV8rzWqy1EW5v9MyfbgNweFMS2GJXHNr1mMiUbmW5clnGphL5 > OhLonEA8FFaceuutePz+LefQiznsbCBljSuKTB4nzy14KY3mDBAyxp3N3SLD+Rno > Aowhp657foWlre652MORmgK7KZWGg8PZ3fxtIuGXFxk9uY0Ib0x3jvvMxm0XWMW0 > BysOmO1LW6kDKUBZSxBh1ZBq4hExySWdn2wT8n4tbYnPdDcun1EjXKSYofKevRXP > +CDY8GER1TpLasiDbL9FHYcEtOIsKgGg85REfB13zlMkUNleTEinM7laLQnUFyIt > hHB7Ua28lykMI3CpaOWDFfNhtzsRW5TRh7DT84OCqnnQQl3vz0Xxr6pg1dPT3M+o > Ns3Hcr/MhgD05sOcA9i3hGRmtpRcYYznqQYdTMSxjb9HWzEjDpk= > =A9OL > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ECDSA Private Keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter, On 1/2/20 04:24, logo wrote: > There may be an issue with the provided/available ciphers! > > The connector comes up correctly, is accessible through the browser > but if I test the ssl setup, I get an error message that the > key/cert may not be used for "Key agreement" > > See: testssl.sh :8443 > > Signature Algorithm ECDSA with SHA256 Server key size > EC 256 bits Server key usage Digital Signature, Key > Encipherment Certificate incorrectly used for key agreement Server > extended key usageTLS Web Server Authentication, TLS Web Client > Authentication > > I cannot find the reason for that yet, testssl complains if there > are TLS_ECDH_*-ciphers with the wrong server key usage. The setup > may be causing troubles in testssl.sh as Tomcat provides ciphers > that maybe should not be available with ECDSA certs (? _RSA??? > Maybe even ECDH_ECDSA???)? > > Testing 370 ciphers via OpenSSL plus sockets against the server, > ordered by encryption strength > > Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption > Bits Cipher Suite Name (IANA/RFC) > -- - --- > > x1302 TLS_AES_256_GCM_SHA384ECDH 256 AESGCM 256 TLS_AES_256_GCM_SHA384 > xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 256 AESGCM > 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 xc024 > ECDHE-ECDSA-AES256-SHA384 ECDH 256 AES 256 > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 xc00a > ECDHE-ECDSA-AES256-SHAECDH 256 AES 256 > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA xc032 > ECDH-RSA-AES256-GCM-SHA384ECDH/RSA AESGCM 256 > TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 xc02e > ECDH-ECDSA-AES256-GCM-SHA384 ECDH/ECDSA AESGCM 256 > TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 xc02a > ECDH-RSA-AES256-SHA384ECDH/RSA AES 256 > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 xc026 > ECDH-ECDSA-AES256-SHA384 ECDH/ECDSA AES 256 > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 xc00f ECDH-RSA-AES256-SHA > ECDH/RSA AES 256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA > xc005 ECDH-ECDSA-AES256-SHA ECDH/ECDSA AES > 256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA x1301 > TLS_AES_128_GCM_SHA256ECDH 256 AESGCM 128 > TLS_AES_128_GCM_SHA256 xc02b ECDHE-ECDSA-AES128-GCM-SHA256 > ECDH 256 AESGCM 128 > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 xc023 > ECDHE-ECDSA-AES128-SHA256 ECDH 256 AES 128 > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 xc009 > ECDHE-ECDSA-AES128-SHAECDH 256 AES 128 > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA xc031 > ECDH-RSA-AES128-GCM-SHA256ECDH/RSA AESGCM 128 > TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 xc02d > ECDH-ECDSA-AES128-GCM-SHA256 ECDH/ECDSA AESGCM 128 > TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 xc029 > ECDH-RSA-AES128-SHA256ECDH/RSA AES 128 > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 xc025 > ECDH-ECDSA-AES128-SHA256 ECDH/ECDSA AES 128 > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 xc00e ECDH-RSA-AES128-SHA > ECDH/RSA AES 128 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA > xc004 ECDH-ECDSA-AES128-SHA ECDH/ECDSA AES > 128 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA > > > Same cert works on the openssl connector (or an apache httpd) and > does not show this issue (only ECDHE key exchange and ECDSA > signature, well openssl does not implement ECDH-ECDSA). > > Testing 370 ciphers via OpenSSL plus sockets against the server, > ordered by encryption strength > > Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption > Bits Cipher Suite Name (IANA/RFC) > -- - --- > > x1302 TLS_AES_256_GCM_SHA384ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 > x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 > 256 TLS_CHACHA20_POLY1305_SHA256 xc02c > ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 xc024 > ECDHE-ECDSA-AES256-SHA384 ECDH 253 AES 256 > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 xc00a > ECDHE-ECDSA-AES256-SHAECDH 253 AES 256 > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA xcca9 > ECDHE-ECDSA-CHACHA20-POLY1305 ECDH 253 ChaCha20256 > TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 xc0af > ECDHE-ECDSA-AES256-CCM8 ECDH 253 AESCCM8 256 > TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 xc0ad ECDHE-ECDSA-AES256-CCM > ECDH 253 AESCCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_CCM > xc073 ECDHE-ECDSA-CAMELLIA256-SHA384ECDH 253 Camellia > 256 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 xc05d > ECDHE-ECDSA-ARIA256-GCM-SHA384ECDH 253 ARIAGCM
Re: HSTS not apply to some request URI path on tomcat 8.5.9 Centos 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pattavee, On 1/1/20 22:55, Pattavee Sanchol wrote: > Dear Chris, > > I follow your suggestion, change my app to ROOT but request with > special characters on url path still response with no HSTS header. > detail on e.g. below > > > [sys01@webgateway ~]$ curl -I -k "https://192.168.136.3:8443; > > HTTP/1.1 200 > > Strict-Transport-Security: max-age=31536000;includeSubDomains > > X-Frame-Options: SAMEORIGIN > > X-Content-Type-Options: nosniff > > X-XSS-Protection: 1; mode=block > > Set-Cookie: > JSESSIONID=11B6A6F834606B167C2281DB1381BBC2;path=/;Secure;HttpOnly > > Content-Type: text/html;charset=UTF-8 > > Transfer-Encoding: chunked > > Date: Thu, 02 Jan 2020 03:46:13 GMT > > > > > [sys01@webgateway ~]$ curl -I -k "https://192.168.136.3:8443/%20; > > HTTP/1.1 200 > > Set-Cookie: > JSESSIONID=DC2234708B03D66FFC6D30178F083145;path=/;Secure;HttpOnly > > Content-Type: text/html;charset=UTF-8 > > Transfer-Encoding: chunked > > Date: Thu, 02 Jan 2020 03:47:54 GMT > > Regards. Can you please package-up a WAR file with the above configuration, name it ROOT.war, deploy it into a fresh Tomcat server and re-test with 8.5.50? If it fails, please post the WAR file somewhere I can fetch it and test it myself. You do not need any additional files except maybe an index.html file to avoid 404 responses. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4OEOgACgkQHPApP6U8 pFgZCRAAxJHr5NHqabbOF1gtEuGKiuF0ZBI3tIF3NXbxv3UhV+sa8xd1XImGVbeU +t21EcmFYY2DEoq42H3NK9QBgHnKALypFaZRFxrVakwfQcRQE9zrkKMYPFmt7rfx ms5wqpCqSYKdn13Ud6vP9c6vfaHJcDQAoAUUrS6Y7c/Otsvtx02bRppz2RClx5+w xnnKzQrUDOFYbpE6Pjw8W09S5UrLFujdPrFS/x+a9mLPa0ve+mT5v1hVTxsaw+Eu oj8mJyIG6ySztP8L2ie6ghLi5aa4j9oSvCIqmLmKbVmMqClj2N70pJV6XDFxKYw3 0Iz8a/7oU7u04giG3I1/VpdKoUlOUBurDjVi2JrjkCCvUp4NS6EM8VOB5EEvcVet qZ6vfEShq5q+o6UWBScQKItSvl61N6aUESMiY9ice6qwAvsJaalDeCZHY1QzHsBY BCCzZX28fMSfaDlE1FPOiFBpMeBiBTSkonjS5D+nj5VF5tLjSus9TBN3/Jr1X1nD hTJOHZGW1HI9YxDQXt/Sx/hvL+IwRhjr61eRaW6c5fWiDPVSYl60FuHAC4oN0Prq 1ws687Aw8OL+U2lOz0GfbfYZC0o3dKUOxUkeaQ/gBBEBiwYmjr7vSWgW9xC9mFkY kukuW01axNc8/Ma4qKIZ563dW78BY5bfWUETBsgr3viQZUjRp+E= =4nX+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ECDSA Private Keys
Felix,
> Am 01.01.2020 um 20:27 schrieb Felix Schumacher
> :
>
>
>> Am 01.01.20 um 18:19 schrieb logo:
>> Felix,
>>
Am 01.01.2020 um 11:49 schrieb Felix Schumacher
:
>>>
>>>
>>> Am 27.12.19 um 17:36 schrieb logo:
Chris
Am 2019-12-27 16:33, schrieb Christopher Schultz:
Peter,
On 12/26/19 18:55, logo wrote:
>>> Hi Mark,
I hope it's okay if I reply. :)
> :-)
>>> I just recently tested Step CA (smallstep.com) as an internal CA
>>> that provides an internal ACME service.
>>>
>>> After I deployed the created cert to my Tomcat (8.5.50 with
>>> adoptopenjdk 11) I noticed that while the openssl connector
>>> immediately started, the JSSE connector with the same cert would
>>> fail with a "java.security.KeyStoreException: Cannot store
>>> non-PrivateKeys“ I use the openssl XML certificate config also for
>>> JSSE.
>>>
>>> It took me quite a while to figure this one out - as the message
>>> usually indicates a public key as cert. I noticed that Step Ca is
>>> creating ECDSA certs by default. The Openssl Connector delivers the
>>> new ECDSA cert just fine.
>>>
>>> While Java (afaik) seems to be able to handle ECDSA, tomcat will
>>> fall through a case statement in
>>> org.apache.tomcat.util.net.jsse.PEMFile
>>>
>>> When loading the PEM file parts it will skip all cases in
>>>
>>> for (Part part : parts) { switch (part.type) { case "PRIVATE KEY":
>>> privateKey = part.toPrivateKey(null, keyAlgorithm, Format.PKCS8);
>>> break; case "ENCRYPTED PRIVATE KEY": privateKey =
>>> part.toPrivateKey(password, keyAlgorithm, Format.PKCS8); break;
>>> case "RSA PRIVATE KEY": privateKey = part.toPrivateKey(null,
>>> keyAlgorithm, Format.PKCS1); break; case "CERTIFICATE": case "X509
>>> CERTIFICATE": certificates.add(part.toCertificate()); break; } }
>>>
>>> as an EC certificate will start with EC PRIVATE KEY.
>>>
>>> Is this something that is expected? ECDSA unsupported? Or just an
>>> incomplete implementation, edge case or a bug?
EC should work. What does your configuration look like?
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
> maxThreads="150"
> SSLEnabled="true" >
>>>> className="org.apache.coyote.http2.Http2Protocol" />
>
> certificateKeyFile="${catalina.base}/conf/ssl/privkey.pem"
> certificateFile="${catalina.base}/conf/ssl/cert.pem"
> />
>
>
> really basic.
> First I had a type attribute "RSA" but even ommitting this didn't
change it.
> Once Tomcat hits the PEMFile-Class the parts read from the
ECDSA-PEM-file are not transferred to a private key so the class
member "privateKey" is null. None of the cases above match "EC PRIVATE
KEY".
>>> The comments at the beginning of PEMFile state that it works for PKCS8,
>>> only. But the code makes an exception for RSA keys, so it probably makes
>>> sense to ad EC keys, too.
>>>
>> Please!
>
> After looking into the code, it doesn't look easy at all.
>
> The code tries to stay away from oracles internal API for cryptography
> and the standard API is not very helpful with regard to EC.
>
>>
>>> Have you tried to convert your key to pkcs8?
>>>
>> Thanks! That works fine!
>>
>> openssl pkcs8 -topk8 -nocrypt -in ssl/privkey.pem -out ssl/privkey-p8.pem
>
>
> Glad it worked.
>
There may be an issue with the provided/available ciphers!
The connector comes up correctly, is accessible through the browser but if I
test the ssl setup, I get an error message that the key/cert may not be used
for "Key agreement"
See:
testssl.sh :8443
Signature Algorithm ECDSA with SHA256
Server key size EC 256 bits
Server key usage Digital Signature, Key Encipherment
Certificate incorrectly used for key agreement
Server extended key usageTLS Web Server Authentication, TLS Web Client
Authentication
I cannot find the reason for that yet, testssl complains if there are
TLS_ECDH_*-ciphers with the wrong server key usage. The setup may be causing
troubles in testssl.sh as Tomcat provides ciphers that maybe should not be
available with ECDSA certs (? _RSA??? Maybe even ECDH_ECDSA???)?
Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by
encryption strength
Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits
Cipher Suite Name (IANA/RFC)
-
x1302 TLS_AES_256_GCM_SHA384ECDH 256 AESGCM 256
