June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-132) Add support for generating certificate signing requests (CSRs)

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-132?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-132: --------------------------------- Summary: Add support for generating certificate signing requests (CSRs) (was: Add support for generating certificate signing requests (CSR)) > Add support for generating certificate signing requests (CSRs) > -------------------------------------------------------------- > > Key: ELY-132 > URL: https://issues.jboss.org/browse/ELY-132 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Certificate Authority > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha1 > > > At some point we want to be able to guide users through the process of generating their own public and private key along with getting a certificate signed by a certificate authority. > Generation of a certificate signing request is going to be essential for that. > https://tools.ietf.org/html/rfc2986 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-131) Add support for the creation of signed certificates.

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-131?page=com.atlassian.jira.plugin.sy... ] David Lloyd updated ELY-131: ---------------------------- Component/s: X.500 > Add support for the creation of signed certificates. > ---------------------------------------------------- > > Key: ELY-131 > URL: https://issues.jboss.org/browse/ELY-131 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Certificate Authority, X.500 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha1 > > > Whilst the standard Java APIs support the creation of public and private keys these APIs do not have a mechanism for creating a signed certificate. > The latest RFC describing the format of these certificates is here: - > https://datatracker.ietf.org/doc/rfc5280/ > Essentially this is about DER encoding of a number of fields combined with signing. > The alternative could to being in something like bouncy castle. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-132) Add support for generating certificate signing requests (CSRs)

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-132?page=com.atlassian.jira.plugin.sy... ] David Lloyd updated ELY-132: ---------------------------- Summary: Add support for generating certificate signing requests (CSRs) (was: Add support for generating certificate signing requests) > Add support for generating certificate signing requests (CSRs) > -------------------------------------------------------------- > > Key: ELY-132 > URL: https://issues.jboss.org/browse/ELY-132 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Certificate Authority > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha1 > > > At some point we want to be able to guide users through the process of generating their own public and private key along with getting a certificate signed by a certificate authority. > Generation of a certificate signing request is going to be essential for that. > https://tools.ietf.org/html/rfc2986 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2078) NPE in Ipv6 Solaris 10 test

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2078?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2078: -------------------------------- I'm sure you wanted to provide some info, didn't you? :-) > NPE in Ipv6 Solaris 10 test > --------------------------- > > Key: JGRP-2078 > URL: https://issues.jboss.org/browse/JGRP-2078 > Project: JGroups > Issue Type: Bug > Reporter: Bogdan Sikora > Assignee: Bela Ban > > {noformat} > {noformat} > {noformat} > {noformat} > {noformat} > {noformat} > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-132) Add support for generating certificate signing requests (CSR)

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-132?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-132: --------------------------------- Summary: Add support for generating certificate signing requests (CSR) (was: Add support for generating certificate signing requests (CSRs)) > Add support for generating certificate signing requests (CSR) > ------------------------------------------------------------- > > Key: ELY-132 > URL: https://issues.jboss.org/browse/ELY-132 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Certificate Authority > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha1 > > > At some point we want to be able to guide users through the process of generating their own public and private key along with getting a certificate signed by a certificate authority. > Generation of a certificate signing request is going to be essential for that. > https://tools.ietf.org/html/rfc2986 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-567) Add a builder API for X.509 certificates

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-567?page=com.atlassian.jira.plugin.sy... ] David Lloyd resolved ELY-567. ----------------------------- Resolution: Duplicate Issue > Add a builder API for X.509 certificates > ---------------------------------------- > > Key: ELY-567 > URL: https://issues.jboss.org/browse/ELY-567 > Project: WildFly Elytron > Issue Type: Feature Request > Components: X.500 > Reporter: David Lloyd > > It is going to be somewhat common for us to generate certificates for various purposes, including (but not limited to) self-signing and CSRs. While it is possible to assemble a certificate by hand using the DER encoding API, it would be nicer to have a certificate builder API which wraps the DER encoder and makes this process easier. It should adhere to all certificate generation rules and recommendations found in RFCs and elsewhere. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2078) NPE in Ipv6 Solaris 10 test

by Bogdan Sikora (JIRA)

Bogdan Sikora created JGRP-2078: ----------------------------------- Summary: NPE in Ipv6 Solaris 10 test Key: JGRP-2078 URL: https://issues.jboss.org/browse/JGRP-2078 Project: JGroups Issue Type: Bug Reporter: Bogdan Sikora Assignee: Bela Ban {noformat} {noformat} {noformat} {noformat} {noformat} {noformat} {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-567) Add a builder API for X.509 certificates

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-567?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-567: --------------------------------- Recently pointed out on the OpenJDK Security Development list: {blockquote} Hi - To be very specific here - if a certificate has extensions, it MUST be version 3, otherwise it SHOULD be version 1, but may be version 2 or 3. (If a certificate has either of the issuer or subject unique ID fields, it must be at least version 2 - but those fields are deprecated as a MUST NOT for conforming CAs, so you should never issue a certificate with those fields). A CA certificate (i.e. an intermediate certificate) is required to have a basicConstraints extension - and must be a version three certificate. If you do this (support V1 cert gen), I'd make it a side effect of whether or not you add extensions instead of a discrete option. {blockquote} > Add a builder API for X.509 certificates > ---------------------------------------- > > Key: ELY-567 > URL: https://issues.jboss.org/browse/ELY-567 > Project: WildFly Elytron > Issue Type: Feature Request > Components: X.500 > Reporter: David Lloyd > > It is going to be somewhat common for us to generate certificates for various purposes, including (but not limited to) self-signing and CSRs. While it is possible to assemble a certificate by hand using the DER encoding API, it would be nicer to have a certificate builder API which wraps the DER encoder and makes this process easier. It should adhere to all certificate generation rules and recommendations found in RFCs and elsewhere. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-567) Add a builder API for X.509 certificates

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-567?page=com.atlassian.jira.plugin.sy... ] David Lloyd edited comment on ELY-567 at 6/8/16 7:46 AM: --------------------------------------------------------- Recently pointed out on the OpenJDK Security Development list: {quote} Hi - To be very specific here - if a certificate has extensions, it MUST be version 3, otherwise it SHOULD be version 1, but may be version 2 or 3. (If a certificate has either of the issuer or subject unique ID fields, it must be at least version 2 - but those fields are deprecated as a MUST NOT for conforming CAs, so you should never issue a certificate with those fields). A CA certificate (i.e. an intermediate certificate) is required to have a basicConstraints extension - and must be a version three certificate. If you do this (support V1 cert gen), I'd make it a side effect of whether or not you add extensions instead of a discrete option. {quote} was (Author: dmlloyd): Recently pointed out on the OpenJDK Security Development list: {blockquote} Hi - To be very specific here - if a certificate has extensions, it MUST be version 3, otherwise it SHOULD be version 1, but may be version 2 or 3. (If a certificate has either of the issuer or subject unique ID fields, it must be at least version 2 - but those fields are deprecated as a MUST NOT for conforming CAs, so you should never issue a certificate with those fields). A CA certificate (i.e. an intermediate certificate) is required to have a basicConstraints extension - and must be a version three certificate. If you do this (support V1 cert gen), I'd make it a side effect of whether or not you add extensions instead of a discrete option. {blockquote} > Add a builder API for X.509 certificates > ---------------------------------------- > > Key: ELY-567 > URL: https://issues.jboss.org/browse/ELY-567 > Project: WildFly Elytron > Issue Type: Feature Request > Components: X.500 > Reporter: David Lloyd > > It is going to be somewhat common for us to generate certificates for various purposes, including (but not limited to) self-signing and CSRs. While it is possible to assemble a certificate by hand using the DER encoding API, it would be nicer to have a certificate builder API which wraps the DER encoder and makes this process easier. It should adhere to all certificate generation rules and recommendations found in RFCs and elsewhere. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2591) CLI can not connect to the server started with port-offset

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-2591: ---------------------------------------- This issue is now closed - please make use of the user forums for assistance http://wildfly.org/gethelp/ > CLI can not connect to the server started with port-offset > ---------------------------------------------------------- > > Key: WFLY-2591 > URL: https://issues.jboss.org/browse/WFLY-2591 > Project: WildFly > Issue Type: Sub-task > Components: CLI > Affects Versions: 8.0.0.Beta1, 8.0.0.Final > Environment: used actual WildFly Beta from github: > commit 96160520ce245d6a85cbb77cad92a021564aa376 > Date: Wed Nov 20 17:05:00 2013 +0100 > Reporter: Wolf-Dieter Fink > Assignee: Darran Lofthouse > Fix For: 8.0.0.Final > > > If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface. > To reproduce start a WildFly Beta server (Alpha3 has the same problem) > bin/standalone.sh -Djboss.socket.binding.port-offset=100 > and a cli client: > bin/jboss-cli.sh -c --controller=localhost:10099 > It makes no difference whether the port is changed by port-offset or configuration. > All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation. > The server log an ERROR message: > ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856 > The jboss-cli.sh client show: > org.jboss.as.cli.CliInitializationException: Failed to connect to the controller > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:292) > at org.jboss.modules.Main.main(Main.java:455) > Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099 > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238) > ... 8 more > Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938) > ... 11 more > Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166) > at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > ... 13 more > Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly > at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:528) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) > at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80) > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99) > ... 23 more -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2016