Re: [Pki-devel] Dogtag PKI is migrating issue tracker from Pagure to GitHub

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Dear users, developers, and maintainers of PKI,


We are happy to announce that the migration of issues from Pagure to Github
was a success.

You can now browse the issues filed against Dogtag PKI on Github:
https://github.com/dogtagpki/pki/issues/


The Pagure Issue tracker is now set to "read-only", to prevent any
comments/modifications that may no longer

be monitored. A link to the associated Github issue has been added as a
comment to the associate Pagure issue

to make it easy for users to track their issues.


All attachments (patches, logs, etc) have been ported to GitHub as well.
So, *none of the information should be*

*lost by this migration.*


All associated Bugzilla bugs have been updated to track the corresponding
new GitHub issues.


If you find any issues, feel free to write back to us and we will try to
fix it! Thanks for your understanding and we apologize

for any inconvenience caused by this migration.


Dogtag PKI Team




On Thu, Oct 1, 2020 at 5:58 PM Dinesh Prasanth Moluguwan Krishnamoorthy <
dmolu...@redhat.com> wrote:

> Dear users, developers and maintainers of PKI,
>
> We, the Dogtag PKI team, have decided to use GitHub issues as our primary
> issue tracker. As a part of the effort to keep things unified, we will be
> migrating all the issues (open and closed) from Pagure Issues
> <https://pagure.io/dogtagpki/issues> to GitHub Issues
> <https://github.com/dogtagpki/pki/issues>.
>
> We see several advantages by this migration:
>
>1.
>
>Reported issues and code stay closer
>2.
>
>Better ways to refer/track issues within PRs and commits
>3.
>
>Better audience outreach
>
>
> When?
>
> Migration starts on Friday, Oct 2 (~5PM EST) and we anticipate it to end
> by Oct 4.
>
> Dry Run Results
>
> https://github.com/pki-bot/pki-issues-final/issues
>
> Process:
>
> We are planning to do the migration in 4 stages.
>
> *Stage 1 (~5 hours):*
>
> Copy all issues from Pagure to GitHub. We have identified and tried to map
> the users from Pagure to GitHub. If your nickname is listed in [1], you’ll
> be receiving github notifications and/or emails. Unfortunately, there is
> no way to keep it down.
>
> *Stage 2 (~2 hours):*
>
> This is a check stage where we test if every Pagure issue has been copied
> to GitHub correctly. There will be no notifications generated
>
> *Stage 3 (~2 hours):*
>
> Add comments to ALL pagure issues and close ALL OPEN pagure issues as
> Migrated. The comment will include a link to the corresponding GH issue.
> We have placed a request [2] to turn off notifications during this stage.
>
> *Stage 4 (~1 hours):*
>
> Update associated bugzilla with link to new GitHub Issues. The “Devel
> Whiteboard” will be updated in the format `PKI ` and an
> external tracker to the GH issue will be added. There will be no
> notifications generated in this stage.
>
>
> Migration Tool:
>
> The tool is available in GH: https://github.com/SilleBille/pagure2github/
>
> Problems?
>
> In case you find any bugs or problems in the migrated tickets, feel free
> to reach out to us via pki-us...@redhat.com
>
> Dogtag PKI Team
>
> [1]
> https://github.com/SilleBille/pagure2github/blob/master/lib/pagure2github/__init__.py#L43-L123
>
>
> [2] https://pagure.io/fedora-infrastructure/issue/9361
>
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] Dogtag PKI is migrating issue tracker from Pagure to GitHub

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Dear users, developers and maintainers of PKI,

We, the Dogtag PKI team, have decided to use GitHub issues as our primary
issue tracker. As a part of the effort to keep things unified, we will be
migrating all the issues (open and closed) from Pagure Issues
 to GitHub Issues
.

We see several advantages by this migration:

   1.

   Reported issues and code stay closer
   2.

   Better ways to refer/track issues within PRs and commits
   3.

   Better audience outreach


When?

Migration starts on Friday, Oct 2 (~5PM EST) and we anticipate it to end by
Oct 4.

Dry Run Results

https://github.com/pki-bot/pki-issues-final/issues

Process:

We are planning to do the migration in 4 stages.

*Stage 1 (~5 hours):*

Copy all issues from Pagure to GitHub. We have identified and tried to map
the users from Pagure to GitHub. If your nickname is listed in [1], you’ll
be receiving github notifications and/or emails. Unfortunately, there is no
way to keep it down.

*Stage 2 (~2 hours):*

This is a check stage where we test if every Pagure issue has been copied
to GitHub correctly. There will be no notifications generated

*Stage 3 (~2 hours):*

Add comments to ALL pagure issues and close ALL OPEN pagure issues as
Migrated. The comment will include a link to the corresponding GH issue. We
have placed a request [2] to turn off notifications during this stage.

*Stage 4 (~1 hours):*

Update associated bugzilla with link to new GitHub Issues. The “Devel
Whiteboard” will be updated in the format `PKI ` and an
external tracker to the GH issue will be added. There will be no
notifications generated in this stage.


Migration Tool:

The tool is available in GH: https://github.com/SilleBille/pagure2github/

Problems?

In case you find any bugs or problems in the migrated tickets, feel free to
reach out to us via pki-us...@redhat.com

Dogtag PKI Team

[1]
https://github.com/SilleBille/pagure2github/blob/master/lib/pagure2github/__init__.py#L43-L123


[2] https://pagure.io/fedora-infrastructure/issue/9361
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] Dogtag Code/Doc Contribution Info Update

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Dear PKI Users and Devels,

Based on recent feedback from the PKI developer community, we have decided
that it’s time to update our documents to formalize a set of well practiced
contributing procedures, and to provide some general guidelines.

The first document is geared to clarify the rules of engagement when it
comes to  CONTRIBUTING
 to our
project. The information also provides tips and best practices when it
comes to the actual development process, with emphasis on how to propose
changes to the PKI source code.

Additionally, we have provided an update to our development related README
  document.  This
document provides a quick and simple way for a developer to become
acclimated to the PKI project itself and how to get started in the
development process.  Some of the major topics covered include installing
the product, deploying the various PKI subsystems on a local host, and
building and submitting for review actual updates to the PKI code base.

Please feel free to contribute to code or documentation or file any bugs
that you may find within the project. Always feel free to reach out to us,
if you have any questions, comments or concerns.

Dogtag PKI Team
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Using Dogtag REST API

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Pascal,

You are sending the parameters via the request's body (which usually is
done in POST). Taking a quick look at the source code [1], seems to me that
you need to pass as GET params.

Example:
   $ curl -k --cert-type P12 --cert ~/ca_admin_cert.p12:Secret.123 https://
:8443/ca/rest/agent/certrequests?requestState=pending&start=15

HTH!

Thanks,
--Dinesh


[1]
https://github.com/dogtagpki/pki/blob/master/base/common/src/com/netscape/certsrv/cert/CertRequestResource.java#L57

On Wed, Jul 8, 2020 at 9:09 AM Pascal Jakobi 
wrote:

> Hi there
>
>
> I created a small python script that just does a "certreqs".
>
> Here is the result :
>
> python3 ./test.py
>
> {"requestState": "pending", "requestType": "any", "start": 5, "pageSize": 0, 
> "maxTime": 100}
>
> Status 200
>
> {'total': 10, 'entries': [
> {'requestType': 'enrollment', 'requestStatus': 'complete', 'requestURL': 
> 'https://auth.iamts.fr:8443/ca/rest/certrequests/1', 'realm': None, 'certId': 
> '0x1', 'certURL': 'https://auth.iamts.fr:8443/ca/rest/certs/1', 
> 'certRequestType': 'pkcs10', 'operationResult': 'success', 'errorMessage': 
> None},
> {'requestType': 'enrollment', 'requestStatus': 'complete', 'requestURL': 
> 'https://auth.iamts.fr:8443/ca/rest/certrequests/2', 'realm': None, 'certId': 
> '0x2', 'certURL': 'https://auth.iamts.fr:8443/ca/rest/certs/2', 
> 'certRequestType': 'pkcs10', 'operationResult': 'success', 'errorMessage': 
> None},
> {'requestType': 'enrollment', 'requestStatus': 'complete', 'requestURL': 
> 'https://auth.iamts.fr:8443/ca/rest/certrequests/3', 'realm': None, 'certId': 
> '0x3', 'certURL': 'https://auth.iamts.fr:8443/ca/rest/certs/3', 
> 'certRequestType': 'pkcs10', 'operationResult': 'success', 'errorMessage': 
> None},
> {'requestType': 'enrollment', 'requestStatus': 'complete', 'requestURL': 
> 'https://auth.iamts.fr:8443/ca/rest/certrequests/4', 'realm': None, 'certId': 
> '0x4', 'certURL': 'https://auth.iamts.fr:8443/ca/rest/certs/4', 
> 'certRequestType': 'pkcs10', 'operationResult': 'success', 'errorMessage': 
> None},
> {'requestType': 'enrollment', 'requestStatus': 'complete', 'requestURL': 
> 'https://auth.iamts.fr:8443/ca/rest/certrequests/5', 'realm': None, 'certId': 
> '0x5', 'certURL': 'https://auth.iamts.fr:8443/ca/rest/certs/5', 
> 'certRequestType': 'pkcs10', 'operationResult': 'success', 'errorMessage': 
> None},
> {'requestType': 'enrollment', 'requestStatus': 'complete', 'requestURL': 
> 'https://auth.iamts.fr:8443/ca/rest/certrequests/6', 'realm': None, 'certId': 
> '0x6', 'certURL': 'https://auth.iamts.fr:8443/ca/rest/certs/6', 
> 'certRequestType': 'pkcs10', 'operationResult': 'success', 'errorMessage': 
> None},
> {'requestType': 'enrollment', 'requestStatus': 'pending', 'requestURL': 
> 'https://auth.iamts.fr:8443/ca/rest/certrequests/7', 'realm': None, 'certId': 
> None, 'certURL': None, 'certRequestType': 'keygen', 'operationResult': 
> 'success', 'errorMessage': None},
> {'requestType': 'enrollment', 'requestStatus': 'pending', 'requestURL': 
> 'https://auth.iamts.fr:8443/ca/rest/certrequests/8', 'realm': None, 'certId': 
> None, 'certURL': None, 'certRequestType': 'keygen', 'operationResult': 
> 'success', 'errorMessage': None},
> {'requestType': 'enrollment', 'requestStatus': 'complete', 'requestURL': 
> 'https://auth.iamts.fr:8443/ca/rest/certrequests/9', 'realm': None, 'certId': 
> '0x7', 'certURL': 'https://auth.iamts.fr:8443/ca/rest/certs/7', 
> 'certRequestType': 'keygen', 'operationResult': 'success', 'errorMessage': 
> None},
> {'requestType': 'enrollment', 'requestStatus': 'complete', 'requestURL': 
> 'https://auth.iamts.fr:8443/ca/rest/certrequests/10', 'realm': None, 
> 'certId': '0x8', 'certURL': 'https://auth.iamts.fr:8443/ca/rest/certs/8', 
> 'certRequestType': 'pkcs10', 'operationResult': 'success', 'errorMessage': 
> None}],
> 'Link': []}
>
> [pascal@dell pki_ui]$
>
>
> This raises 2 questions.
> 1/ I requested "pending" cert reqs. But I get also "complete" reqs. Any
> idea why ?
> 2/ I set the start field to 5, but I receive all requests. Again why is
> that ?
>
> Thxs again for your help
>
>
> --
> *Pascal Jakobi* 116 rue de Stalingrad 93100 Montreuil, France
> pascal.jak...@gmail.com - +33 6 87 47 58 19
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] SSO

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Pascal,

I don't think Dogtag Web UI supports it. The feature you are suggesting
(sounds to me like it) requires a full fledged IDM deployment. You can look
at FreeIPA, if you are looking for MFA.

FreeIPA  uses Dogtag CA as its backend
to issue certs and also combines several other components to offer a
full-fledged IDM deployment.

Nonetheless, I'm CC'ing pki-devel to see if other developers have any
thoughts.

Regards,
--Dinesh

On Mon, Jun 29, 2020 at 4:47 PM Pascal Jakobi 
wrote:

> Dinesh
>
> In fact all I am doing here is in order to offer a GUI that may be used
> with OpenId Connect (ie Keycloak or so...). The value of this is that it is
> much more flexible than certificate based authentication. You can have MFA,
> etc
>
> So my question : is there a way to remove the certificate based access
> control in Dogtag's UI ? I would replace it with a tomcat valve that
> provides OIDC support.
>
> Best
> --
> *Pascal Jakobi* 116 rue de Stalingrad 93100 Montreuil, France
> pascal.jak...@gmail.com - +33 6 87 47 58 19
>
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Questions regarding addition of our own Cockpit module

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hello team,

We discussed the possibility of using Cockpit in Dogtag PKI with our whole

team (including Devs, QEs, CEE, POs and PMs). It seems that the proposed

solutions by Martin and Simon seem to require major architectural changes to

Dogtag PKI product itself, which, as Fraser pointed out, circles back to the

requirement of full-fledged IDM environment.

So, as of now, we have decided to use the PatternFly and ReactJS directly to

design our web interface (to stay as close to the cockpit design as
possible).


Regards,

--Dinesh

On Mon, Jun 8, 2020 at 8:36 AM Simon Kobyda  wrote:

> On Fri, 2020-06-05 at 11:13 +0200, Martin Pitt wrote:
> > Hello Dinesh,
> >
> > Dinesh Prasanth Moluguwan Krishnamoorthy [2020-06-03 20:17 -0400]:
> > > I’m part of Dogtag PKI open-source project [1]. Our team strives to
> > > provide
> > > enterprise-class open-source Public Key Infrastructure (PKI) [2].
> >
> > FTR, Simon Kobyda (CCed) is working on a Cockpit page for managing
> > certificates
> > [1]. There may be some overlap here, so perhaps you can meet and
> > exchange some
> > ideas.
> >
>
> This sounds interesting. Is this module of yours (as I guess from email
> subject) mainly oriented for Smart Cards? What use cases does it look
> to solve?
> The module I'm working on is so far oriented about functionalities
> provided by certmonger. It provides UI to functionalities such
> requesting and tracking certificate, importing preexisting certificate
> & key and renewing and resubmiting it.
> It can request certificate from CA configured to certmonger like IPA.
> The module so far doesn't have hard set limitations so it can be
> expanded (for example outside of scope of just certmonger) if we find
> some overlap.
>
> > > 1. According to [3] Cockpit seems to require the host to join the
> > > IdM
> > > domain in order to authenticate PKI users into Cockpit using client
> > > cert
> > > auth. Is it possible to use client cert auth without joining a
> > > domain? Will
> > > that require major changes in Cockpit?
> >
> > To be precise, Cockpit calls sssd to map a given certificate from TLS
> > client
> > cert auth to a user [2], with FindByCertificate().
> >
> > This doesn't *inherently* require IdM. It's just (1) the only way how
> > I got
> > that sssd lookup mechanism to actually work, and (2) it generally
> > makes sense
> > to maintain this cert→user mapping centrally.
> >
> > Allegedly it is possible to configure sssd to do this mapping with
> > local
> > certificates [2]. I played around with that a few weeks ago, as that
> > would be a
> > very interesting use case, but I didn't manage to get it working --
> > apparently
> > the FindByCertificate() sssd method only works with IdM, not with
> > these local
> > certificates. Making that work may be an interesting project.
> >
> > So this all hinges on sssd -- if that can map a certificate, you can
> > log into
> > Cockpit. Cockpit itself would need no modifications for backends
> > other than
> > FreeIPA.
> >
> > > 2. Suppose the user has been authenticated into Cockpit using a
> > > client cert
> > > as described in #1, is it possible for Cockpit to use the same
> > > client
> > > certificate auth to access PKI server? Or do we need to use a
> > > different
> > > auth mechanism?
> >
> > As Fraser already pointed out, cockpit's web server doesn't have the
> > private
> > key that the browser end was using to authenticate, so that doesn't
> > work.
> >
> > Does it have to be TLS client cert auth,  or would kerberos work as
> > well? We
> > are currently designing that so that we can "forward" (or rather,
> > convert/transcend) the initial client cert auth to a kerberos ticket,
> > so that
> > cockpit can use that to further authenticate to services like sudo or
> > ssh.
> > Structurally that's very similar, but it would require the PKI server
> > to accept
> > delegated (S4U) kerberos tickets.
> >
> > Martin
> >
> >
> > [1] https://github.com/skobyda/cockpit-certificates
> > [2]
> >
> https://docs.pagure.org/SSSD.sssd/design_pages/lookup_users_by_certificate.html
> > [3]
> >
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_authselect_on_a_red_hat_enterprise_linux_host/configuring-and-importing-local-certificates-to-a-smart-card_using_authselect_on_a_red_hat_enterprise_linux_host
> > [4] https://p

[Pki-devel] Questions regarding addition of our own Cockpit module

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hello team,

I’m part of Dogtag PKI open-source project [1]. Our team strives to provide
enterprise-class open-source Public Key Infrastructure (PKI) [2].

Dogtag PKI server is a Java web application running on Tomcat. Currently,
we have a stand-alone Java AWT client tool called pkiconsole to access PKI
services on the server. PKI users are authenticated using client
certificates stored in LDAP. These users only exist in LDAP, they are not
users on the host itself.

We are trying to convert pkiconsole into a web application. We had a chance
to look at Cockpit from a very high-level and have some questions. I’m
reaching out to the members of the Cockpit team, before we could make a
concrete decision on whether Cockpit is a perfect choice for us.

The questions are:

1. According to [3] Cockpit seems to require the host to join the IdM
domain in order to authenticate PKI users into Cockpit using client cert
auth. Is it possible to use client cert auth without joining a domain? Will
that require major changes in Cockpit?

2. Suppose the user has been authenticated into Cockpit using a client cert
as described in #1, is it possible for Cockpit to use the same client
certificate auth to access PKI server? Or do we need to use a different
auth mechanism?

Regards,
The PKI Team

[1] https://github.com/dogtagpki/pki

[2] https://www.dogtagpki.org/wiki/PKI_Main_Page

[3] https://cockpit-project.org/guide/latest/cert-authentication
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] Questions regarding addition of our own Cockpit module

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hello team,

I’m part of Dogtag PKI open-source project [1]. Our team strives to provide
enterprise-class open-source Public Key Infrastructure (PKI) [2].

Dogtag PKI server is a Java web application running on Tomcat. Currently,
we have a stand-alone Java AWT client tool called pkiconsole to access PKI
services on the server. PKI users are authenticated using client
certificates stored in LDAP. These users only exist in LDAP, they are not
users on the host itself.

We are trying to convert pkiconsole into a web application. We had a chance
to look at Cockpit from a very high-level and have some questions. I’m
reaching out to the members of the Cockpit team before we could make a
concrete decision on whether Cockpit is a perfect choice for us.

The questions are:

1. According to [3] Cockpit seems to require the host to join the IdM
domain in order to authenticate PKI users into Cockpit using client cert
auth. Is it possible to use client cert auth without joining a domain? Will
that require major changes in Cockpit?

2. Suppose the user has been authenticated into Cockpit using a client cert
as described in #1, is it possible for Cockpit to use the same client
certificate auth to access PKI server? Or do we need to use a different
auth mechanism?

Regards,
The PKI Team

[1] https://github.com/dogtagpki/pki

[2] https://www.dogtagpki.org/wiki/PKI_Main_Page

[3] https://cockpit-project.org/guide/latest/cert-authentication
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Configuration of Friendly Name and Country

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hi Nadeera,

Please find my reply inline

On Fri, May 29, 2020 at 5:28 AM Nadeera Galagedara <
nadeeragalaged...@yahoo.com> wrote:

> Dear Dinesh,
>
> I tried the method and still have the problem. I will tell you what i did
> and can you tell me where did I do wrong.
>
> My root CA has "*Maximum number of intermediate CAs: unlimited*" and now
> I am installing the issuing ca (what I use for to issue certificates for
> clients). For the issuing *CA **Maximum number of intermediate* CAs want
> to be *Zero*.
>

> I basically follow
> https://www.dogtagpki.org/wiki/PKI_10.5_Installing_CA_with_External_CA_Signing_Certificate
>  steps
> (send the CSR to root CA and get back the signed certificate) and added
>
> policyset.caCertSet.5.default.name=Basic Constraints Extension Default
> policyset.caCertSet.5.default.params.basicConstraintsCritical=true
> policyset.caCertSet.5.default.params.basicConstraintsIsCA=true
> policyset.caCertSet.5.default.params.basicConstraintsPathLen=0
>
> lines to both step 1 and step 2 config files and installed the Issuing CA.
>
The above lines need to be added to profiles, not to .cfg for pkispawn. My
colleague, Fraser, wrote an awesome blog post [1] explaining how Dogtag
profiles work. Though the post was written in 2014 this should give you a
good understanding of how to configure profiles.

But, in your case, I believe you need to craft the CSR with this
constraint. So, you need to use the `openssl` or `certutil` tools to
specify the *basic Constraint*.

For example, using openssl:

openssl req \
-addext basicConstraints=critical,CA:TRUE,pathlen:1 \

...


You can also refer how to create CSR in our wiki [2]

[1]
https://frasertweedale.github.io/blog-redhat/posts/2014-05-14-dogtag-profile-definitions.html
[2] https://www.dogtagpki.org/wiki/Generating_CA_Signing_CSR_with_OpenSSL

HTH. Good luck!

Regards,
--Dinesh


> Then I went to the Issuing CA's * "SSL End Users Services" *-> "*Manual
> User Dual-Use Certificate **Enrollment"* and created a certificate.  Then
> I wend to *Agent Services* and approve that request.
>
> I imported that certificate to browser. But still it shows my issuing CA 
> *Maximum
> number of intermediate CAs: unlimited. *
>
> Can you tell me what did I do wrong.
>
>
> On Friday, May 22, 2020, 11:27:29 PM GMT+5:30, Dinesh Prasanth Moluguwan
> Krishnamoorthy  wrote:
>
>
> Nadeera,
>
> (CC'ing pki-devel)
>
> Setting the number of intermediate CAs can be achieved by using "Basic
> Constraints Extension" [1] and setting the PathLen= to the required value.
>
> You need to set this extension on a CA profile and then issue a CA signing
> cert. You can't modify this value on an already issued CA cert. Read more
> on how to add this constraint to a profile here [2]
>
> [1]
> https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html-single/administration_guide_common_criteria_edition/index#Basic_Constraints_Extension_Default
> [2]
> https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html-single/administration_guide_common_criteria_edition/index#about-extensions
>
> Regards,
> --Dinesh
>
> On Fri, May 22, 2020 at 8:57 AM Nadeera Galagedara <
> nadeeragalaged...@yahoo.com> wrote:
>
> Dear Dinesh,
>
> I want another help from you. How can I change the "Maximum number of
> intermediate CAs: unlimited" value.
> On Friday, May 22, 2020, 10:57:45 AM GMT+5:30, Nadeera Galagedara <
> nadeeragalaged...@yahoo.com> wrote:
>
>
> Dear Dinesh,
>
> That is a great explanation. That problem that problem is also solved.
> Again thank you.
>
> On Wednesday, May 20, 2020, 08:27:56 PM GMT+5:30, Dinesh Prasanth
> Moluguwan Krishnamoorthy  wrote:
>
>
> Hi Nadeera,
>
> I'm glad I could resolve your issues.
>
> As for the friendly/nickname, these names are customizable based on the
> system you use and are not specified during the certificate issuance.
>
> For instance, when you specified "
> *pki_ca_signing_nickname=mycompany_nickname"* this nickname was used to
> import the CA system certificate in your PKI server's NSSDB. You can view
> this by doing `certutil -L -d /etc/pki/pki-tomcat/alias` and you should see
> the *mycompany_nickname* listed.
>
> I have very limited knowledge of handling certificates in windows. From
> Googling around: you can try to *right-click on the certificate ->
> Properties -> "general" tab -> Set "Friendly Name"*.
>
> HTH
>
> Regards,
> --Dinesh
>
> On Wed, May 20, 2020 at 3:28 AM Nadeera Galagedara <
> nadeeragalaged...@yahoo.com> wrote:
>
> Dear Dinesh,
>
> Tha

Re: [Pki-devel] Configuration of Friendly Name and Country

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Nadeera,

(CC'ing pki-devel)

Setting the number of intermediate CAs can be achieved by using "Basic
Constraints Extension" [1] and setting the PathLen= to the required value.

You need to set this extension on a CA profile and then issue a CA signing
cert. You can't modify this value on an already issued CA cert. Read more
on how to add this constraint to a profile here [2]

[1]
https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html-single/administration_guide_common_criteria_edition/index#Basic_Constraints_Extension_Default
[2]
https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html-single/administration_guide_common_criteria_edition/index#about-extensions

Regards,
--Dinesh

On Fri, May 22, 2020 at 8:57 AM Nadeera Galagedara <
nadeeragalaged...@yahoo.com> wrote:

> Dear Dinesh,
>
> I want another help from you. How can I change the "Maximum number of
> intermediate CAs: unlimited" value.
> On Friday, May 22, 2020, 10:57:45 AM GMT+5:30, Nadeera Galagedara <
> nadeeragalaged...@yahoo.com> wrote:
>
>
> Dear Dinesh,
>
> That is a great explanation. That problem that problem is also solved.
> Again thank you.
>
> On Wednesday, May 20, 2020, 08:27:56 PM GMT+5:30, Dinesh Prasanth
> Moluguwan Krishnamoorthy  wrote:
>
>
> Hi Nadeera,
>
> I'm glad I could resolve your issues.
>
> As for the friendly/nickname, these names are customizable based on the
> system you use and are not specified during the certificate issuance.
>
> For instance, when you specified "
> *pki_ca_signing_nickname=mycompany_nickname"* this nickname was used to
> import the CA system certificate in your PKI server's NSSDB. You can view
> this by doing `certutil -L -d /etc/pki/pki-tomcat/alias` and you should see
> the *mycompany_nickname* listed.
>
> I have very limited knowledge of handling certificates in windows. From
> Googling around: you can try to *right-click on the certificate ->
> Properties -> "general" tab -> Set "Friendly Name"*.
>
> HTH
>
> Regards,
> --Dinesh
>
> On Wed, May 20, 2020 at 3:28 AM Nadeera Galagedara <
> nadeeragalaged...@yahoo.com> wrote:
>
> Dear Dinesh,
>
> Thank you for your support and it is been very helpful. I am using Centos
> 7 and the version came with it is 10.5. I am using that version. I think I
> have corrected the country (with c=LK). But I still have a problem with the
> nickname.
>
> I used the *pki_ca_signing_nickname=mycompany_nickname* line but still
> the friendly name show on windows PC (I have imported the issued
> certificate to a windows PC) format like 's  ID.
> My requirement is to show the the Friendly Name (shows as in Windows PC) as
> "*mycompany_nickname* " I have attached a screenshot also. Please tell me
> what did I do wrong.
>
>
> [image: Inline image]
>
>
> The full config is mentioned below
>
>
> *Step 1*
>
> *[CA]*
> *pki_admin_email=mycomp...@abc.lk *
> *pki_admin_name=caadmin*
> *pki_admin_nickname=caadmin*
> *pki_admin_password=Secret.123*
> *pki_admin_uid=caadmin*
>
> *pki_client_database_password=Secret.123*
> *pki_client_database_purge=False*
> *pki_client_pkcs12_password=Secret.123*
>
> *pki_ds_base_dn=dc=issueca,dc=mycompany,dc=lk*
> *pki_ds_database=ca2*
> *pki_ds_password=Secret.123*
>
> *pki_security_domain_name=mycompany_domain*
> *pki_token_password=Secret.123*
>
> *pki_external=True*
> *pki_external_step_two=False*
>
>
> *pki_ca_signing_subject_dn=cn=mycompany_cn,ou=mycompany_ou,o=mycompany_o,c=LK*
> *pki_ca_signing_csr_path=ca_signing.csr*
>
> *pki_ca_signing_nickname=mycompany_nickname*
>
> *pki_default_ocsp_uri=http://ocsp.mycompany.lk <http://ocsp.mycompany.lk>*
>
>
>
> *Step 2*
>
> *[CA]*
> *pki_admin_email=mycomp...@abc.lk *
> *pki_admin_name=caadmin*
> *pki_admin_nickname=caadmin*
> *pki_admin_password=Secret.123*
> *pki_admin_uid=caadmin*
>
> *pki_client_database_password=Secret.123*
> *pki_client_database_purge=False*
> *pki_client_pkcs12_password=Secret.123*
>
> *pki_ds_base_dn=dc=issueca,dc=mycompany,dc=lk*
> *pki_ds_database=ca2*
> *pki_ds_password=Secret.123*
>
> *pki_security_domain_name=mycompany_domain*
> *pki_token_password=Secret.123*
>
> *pki_external=True*
> *pki_external_step_two=True*
>
> *pki_ca_signing_csr_path=ca_signing.csr*
> *pki_ca_signing_cert_path=ca_signing.crt*
>
> *pki_ca_signing_nickname=mycompany_nickname*
>
> *pki_default_ocsp_uri=http://ocsp.mycompany.lk <http://ocsp.mycompany.lk>*
>
>
>
>
> Thank you and best regards,
> Nadeera.
>
>
>
>
>
> On Wednesd

Re: [Pki-devel] Configuration of Friendly Name and Country

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hi Nadeera,

What version of dogtag PKI are you trying to install? You are referring to
PKI 10.5 docs. The latest release is 10.8.3

If you are using the latest packages, our docs are available in our
upstream repo: https://github.com/dogtagpki/pki/tree/v10.8/docs

(see inline reply)

On Tue, May 19, 2020 at 9:22 AM Nadeera Galagedara <
nadeeragalaged...@yahoo.com> wrote:

> Dear all,
>
> I am new to dogtag and I am installing a sub ca using the method
> described  in
> https://www.dogtagpki.org/wiki/PKI_10.5_Installing_CA_with_External_CA_Signing_Certificate
> . I want to know.
>
> 1) What is the parameter to change the *Friendly Name*
>
We do not use "Friendly Name". Instead, we use "nickname"
To configure the nickname for CA signing certificate use:
pki_ca_signing_nickname=

2) What is the parameter to change the *Country/Locality*
>
This is set using subject dn. So, in your case specify the Country using
this attribute: pki_ca_signing_subject_dn=


> 3) Where (a page link ) I can find details about each of this
> configuration parameters.
>
I don't have a page that explains all the config parameters. But, I do have
a page that can give you a list of parameters that you can use (since you
mentioned 10.5, I'm listing the contents of 10.5 branch. Refer to the
appropriate branch for an updated list)
https://github.com/dogtagpki/pki/blob/DOGTAG_10_5_BRANCH/base/server/etc/default.cfg

HTH

Regards,
--Dinesh


>
> Thank you.
>
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] PKI 10.8.3 is available upstream!

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hello everyone,

PKI 10.8.3 is now available upstream:
https://github.com/dogtagpki/pki/releases/tag/v10.8.3

Fedora builds have been made and submitted to Bodhi for testing:
F30: 
https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ce7aa6d82
F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-86a3576a8a
F32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5f05c3ec46

Fedora Rawhide builds are also available.

We welcome testing and feedback for the update.

Regards,
PKI Team


signature.asc
Description: This is a digitally signed message part
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] How to find the private key Dogtag

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hello Sharath,

(responding to your "To retrieve private key" email as well)

You can start by looking at:
https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/html/administration_guide/key_recovery_authority

For CLI instructions, refer:
https://www.dogtagpki.org/wiki/Certificate_Key_Archival

https://www.dogtagpki.org/wiki/PKI_KRA_Key_CLI


OR

For GUI, you can retrieve the PKCS#12 (.p12) file from the KRA Web UI:
https://:/kra

You can obtain the above URL by running `pkidaemon status` in the
server where you have KRA installed

Note that you need to import KRA Admin cert into browser in order to
retrieve keys

If you need more assistance, please feel free to reach out!

Good luck!

Regards,
--Dinesh


On Wed, 2019-11-06 at 19:30 +0530, Sharath wrote:
> Hello Team,
> 
> I have certificate and the public key but where i can find the
> private 
> key ??
> 
> pki ca-cert-show 0x30 --output myCert.cer
> 
> Key ID: 0x1a
>Algorithm: 1.2.840.113549.1.1.1
>Size: 1024
>Owner: CN=test_sharath01,O=tecra
>Public Key:
> 
> MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCZNLvZQ+WVnBBHM3nw3UldIdVi
> droNReev+/iMyaLlvuof4io2V1Yv8oT5Yhfxuoblt+nqdWpAwgFeTHKxTpVmyNpZ
> UiyEdhLssIJ5cPGZ0BjRKjehsapPCMZzslvFbVG8Rb8E0md0av9ncJBcM9caicRz
> 7qeRqqunXFtvfViZ2QIDAQAB
> 
> pki -d ~/.dogtag/nssdb -c Secret@123 -n "PKI Administrator for 
> tecra-db02" kra-key-show  0x1a
> 
> 
>Key ID: 0x1a
>Algorithm: 1.2.840.113549.1.1.1
>Size: 1024
>Owner: CN=test_sharath01,O=tecra
>Public Key:
> 
> MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCZNLvZQ+WVnBBHM3nw3UldIdVi
> droNReev+/iMyaLlvuof4io2V1Yv8oT5Yhfxuoblt+nqdWpAwgFeTHKxTpVmyNpZ
> UiyEdhLssIJ5cPGZ0BjRKjehsapPCMZzslvFbVG8Rb8E0md0av9ncJBcM9caicRz
> 7qeRqqunXFtvfViZ2QIDAQAB
> 
> 
> Thanks,
> 
> Sharath
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel


signature.asc
Description: This is a digitally signed message part
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] How generate the pkcs12 certificate Dogtag

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hello Sharath,

There are different type of certificates that can be generated using
Dogtag. You can learn more here: 
https://www.dogtagpki.org/wiki/Certificate_Management

This document should help you get started with generic certificates: 
https://www.dogtagpki.org/wiki/PKI_CA_Certificate_CLI

Regards,
--Dinesh

On Wed, 2019-11-06 at 17:50 +0530, Sharath wrote:
> Hello Team,
> 
> Can you please help  "How to generate the private key and associated 
> certificate(matching to the Private Key) using Dogtag" ??
> 
> Thanks,
> 
> Sharath
> 
> 
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel


signature.asc
Description: This is a digitally signed message part
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] New Release: PKI 10.7.3 is available for testing

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hello everyone!

We, the PKI Team, are happy to announce a new release for Dogtag PKI
(and its deps) and is ready for some testing.

Fedora 30 builds:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-0c32c4775a

Fedora 29 builds:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-9a306c181a

Fedora Rawhide builds are available in Koji stable repo.

PKI 10.7.3 source is now available upstream:
https://github.com/dogtagpki/pki/releases/tag/v10.7.3

We'd be glad to hear feedback on the new release and will help us to
push it to stable, quicker.

Regards,
--Dinesh


signature.asc
Description: This is a digitally signed message part
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] New Release: PKI 10.7.0 now available

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hello everyone!

We are happy to announce the next new release of PKI 10.7.0 and its deps.

Brief of what's updated:
- New JSS release 4.5.3-2
- Rebase tomcatjss to 7.4.0
- Rebase PKI to 10.7.0

PKI 10.7.0 is now available upstream:
https://github.com/dogtagpki/pki/releases/tag/v10.7.0

Fedora 30 builds are available via the following update:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-1337735a42

Fedora 29 builds are available via the following update:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-40e2ad6d2c

Fedora Rawhide builds are also available in Koji.

We have official COPR builds available at:
https://copr.fedorainfracloud.org/coprs/g/pki/master/

Please feel free to try it out. We would love to hear back from you! Happy
testing!

Regards,
--Dinesh
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Dogtag+FreeIPA: adapting to the Fedora mass orphaning

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Here is my take on moving to modules (speaking from dogtag side of
things):
Pros:
* We would be version-focused instead of fedora-release focused [1]*
One source for multiple fedora-release [2]* Dogtag's future would be as
described in [3]
Cons:
* Dogtag's CI runs on Travis. Moving into modules would break the CI
workflow leading to a major restructure of upstream CI* In addition to
official releases via koji/bodhi, we do maintain an official COPR repo
(@pki/10.x). This would need to be reconfigured* Dogtag's nightlies run
on COPR. This would again need to be reconfigured.
Though in future modules MIGHT help us, the effort required to move
into modules (and to make it work) is releatively VERY HIGH.
[1] 
https://docs.fedoraproject.org/en-US/modularity/architecture/building/#_modular_package_builds[2
] 
https://docs.fedoraproject.org/en-US/modularity/architecture/building/#_building_one_source_for_multiple_releases[3
] https://i.ibb.co/23nbNWK/module-branching.jpg
> Of course, we can move FreeIPA to a module relatively fast in
> Rawhide.
> But first we need to understand whether the same is possible for
> Dogtag.
> 
> -- 
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> 
> ___
> Pki-devel mailing list
> Pki-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] New Release: PKI-10.6.9 and JSS-4.5.2

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hi everyone!

I'm happy to announce the next new release of PKI 10.6.9 and JSS 4.5.2.

PKI 10.6.9 is now available upstream:
https://github.com/dogtagpki/pki/releases/tag/v10.6.9
https://github.com/dogtagpki/jss/releases/tag/v4.5.2

Fedora 29 builds are available via the following update:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-7f8a0793f1
https://bodhi.fedoraproject.org/updates/FEDORA-2019-94922829c1

Fedora 28 builds are available via the following update:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-10739882f4
https://bodhi.fedoraproject.org/updates/FEDORA-2019-a9f84d8cf6

Fedora Rawhide builds are available in Koji.

We have official COPR builds available at: 
https://copr.fedorainfracloud.org/coprs/g/pki/10.6/builds/

Please feel free to try it out. We would love to hear issues/feedbacks
from you!

Regards,
Dinesh

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] New release: PKI 10.6.8

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hi everyone!

I'm happy to announce a new release of PKI and its dependencies.

PKI 10.6.8 is now available upstream:
https://github.com/dogtagpki/pki/releases/tag/v10.6.8

Fedora 29 builds are available via the following update:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-3241dd6a7f

Fedora 28 builds are available via the following update:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-115068f60e

Fedora Rawhide builds are available in Koji. 

Please feel free to try it out. We would love to hear feedbacks from
you!

Regards,
Dinesh


___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] New update: PKI 10.6.7 and its deps

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Ok, I have an update which I think is the reason for the failure.

We placed 2 bodhi updates as follows:

(1) tomcatjss 7.3.6-1
(2) nuxwdog 1.0.5-2, dogtag-pki 10.6.7-1, pki-core 10.6.7-1

(However, for F29, all were combined into a single bodhi update. That's
why there were no issues reported against F29)

The problem is that we changed the deps for pki-core 10.6.7-1 to
require tomcatjss 7.3.6. Since they were placed as 2 separated updates,
bodhi is intentionally configured to avoid packages from a different
bodhi update entry.

Solution:
(1) Tomcatjss goes to stable in a day (10/12). We wait a day and ask
the openqa folks to retrigger the test (Recommended)
(2) We do a -2 release for tomcatjss and combine it with the existing
pki-core bodhi update -- tomcatjss 7.3.6-1 will be obsolete
automatically

The problem I see with (2) approach is that this will not only break
the sync that exists between packages in RHEL/Fedora but also between
Fedora release itself.


Regards,
Dinesh


On Thu, 2018-10-11 at 10:39 -0400, Dinesh Prasanth Moluguwan
Krishnamoorthy wrote:
> Hi Fraser,
> 
> What baffles me the most is that, we have a nightly test that tries
> to
> pull the latest "stable" IPA and runs all cert related tests. Our
> nightly CI should have been the one which should have caught this
> error
> before, but it didn't. :\
> 
> This nightly ran on Oct 11 -- 
> https://travis-ci.org/dogtagpki/pki-nightly-test/jobs/439957658#L2674
> 
> As you can see, FreeIPA 4.7.0-3.fc28.x86_64 was installed and all the
> tests passed. openqa uses the same version of IPA and Dogtag. May be
> we
> can ask to try retriggering the openqa test. Any thoughts?
> 
> Regards,
> Dinesh
> 
> On Thu, 2018-10-11 at 22:58 +1000, Fraser Tweedale wrote:
> > Dear Dinesh,
> > 
> > The 10.6.7-1 update[1] was given negative karma due to FreeIPA
> > installation failure[2] on openqa.  I have spent considerable time
> > trying to reproduce the failure using the same package from
> > updates-testing, without success.
> > 
> > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2018-83e180a755
> > [2] https://openqa.fedoraproject.org/tests/291997
> > 
> > The error in the openqa logs seems to be something to do with the
> > resteasy jackson provider and inability to construct the
> > ConfigurationRequest class.  Says it can't see the zero-arg
> > constructor... (it's definitely there!)
> > 
> > I'm on PTO tomorrow but keep me in the loop if you make any
> > progress.
> > 
> > Cheers,
> > Fraser
> > 
> > On Fri, Oct 05, 2018 at 12:07:22PM -0400, Dinesh Prasanth Moluguwan
> > Krishnamoorthy wrote:
> > > Hi everyone,
> > > Today, we have released a new update of pki-core and its
> > > dependencies.
> > > PKI 10.6.7 is now available upstream:
> > > https://github.com/dogtagpki/pki/releases/tag/v10.6.7Tomcatjss
> > > 7.3.6 is
> > > now available upstream:
> > > https://github.com/dogtagpki/tomcatjss/releases/tag/v7.3.6
> > > Fedora 28 builds are available via the following update:pki-core,
> > > nuxwdog, dogtag-pki: 
> > > 
> 
> 
https://bodhi.fedoraproject.org/updates/pki-core-10.6.7-1.fc28%20nuxwdog-1.0.5-2.fc28%20dogtag-pki-10.6.7-1.fc28tomcatjss
> > > :
> > >  https://bodhi.fedoraproject.org/updates/FEDORA-2018-5558d54d37
> > > Fedora 29 builds are available via the following update:pki-core,
> > > nuxwdog, dogtag-pki, tomcatjss:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2018-fd68715f9c
> > > Rawhide builds are available in Koji.
> > > Fedora 27 builds are available in this COPR repository:
> > > https://copr.fedorainfracloud.org/coprs/g/pki/10.6/
> > > Regards,Dinesh
> > > ___
> > > Pki-devel mailing list
> > > Pki-devel@redhat.com
> > > https://www.redhat.com/mailman/listinfo/pki-devel
> > 
> > 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] New update: PKI 10.6.7 and its deps

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hi Fraser,

What baffles me the most is that, we have a nightly test that tries to
pull the latest "stable" IPA and runs all cert related tests. Our
nightly CI should have been the one which should have caught this error
before, but it didn't. :\

This nightly ran on Oct 11 -- 
https://travis-ci.org/dogtagpki/pki-nightly-test/jobs/439957658#L2674

As you can see, FreeIPA 4.7.0-3.fc28.x86_64 was installed and all the
tests passed. openqa uses the same version of IPA and Dogtag. May be we
can ask to try retriggering the openqa test. Any thoughts?

Regards,
Dinesh

On Thu, 2018-10-11 at 22:58 +1000, Fraser Tweedale wrote:
> Dear Dinesh,
> 
> The 10.6.7-1 update[1] was given negative karma due to FreeIPA
> installation failure[2] on openqa.  I have spent considerable time
> trying to reproduce the failure using the same package from
> updates-testing, without success.
> 
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2018-83e180a755
> [2] https://openqa.fedoraproject.org/tests/291997
> 
> The error in the openqa logs seems to be something to do with the
> resteasy jackson provider and inability to construct the
> ConfigurationRequest class.  Says it can't see the zero-arg
> constructor... (it's definitely there!)
> 
> I'm on PTO tomorrow but keep me in the loop if you make any
> progress.
> 
> Cheers,
> Fraser
> 
> On Fri, Oct 05, 2018 at 12:07:22PM -0400, Dinesh Prasanth Moluguwan
> Krishnamoorthy wrote:
> > Hi everyone,
> > Today, we have released a new update of pki-core and its
> > dependencies.
> > PKI 10.6.7 is now available upstream:
> > https://github.com/dogtagpki/pki/releases/tag/v10.6.7Tomcatjss
> > 7.3.6 is
> > now available upstream:
> > https://github.com/dogtagpki/tomcatjss/releases/tag/v7.3.6
> > Fedora 28 builds are available via the following update:pki-core,
> > nuxwdog, dogtag-pki: 
> > 
https://bodhi.fedoraproject.org/updates/pki-core-10.6.7-1.fc28%20nuxwdog-1.0.5-2.fc28%20dogtag-pki-10.6.7-1.fc28tomcatjss
> > :
> >  https://bodhi.fedoraproject.org/updates/FEDORA-2018-5558d54d37
> > Fedora 29 builds are available via the following update:pki-core,
> > nuxwdog, dogtag-pki, tomcatjss:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2018-fd68715f9c
> > Rawhide builds are available in Koji.
> > Fedora 27 builds are available in this COPR repository:
> > https://copr.fedorainfracloud.org/coprs/g/pki/10.6/
> > Regards,Dinesh
> > ___
> > Pki-devel mailing list
> > Pki-devel@redhat.com
> > https://www.redhat.com/mailman/listinfo/pki-devel
> 
> 

___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] New update: PKI 10.6.7 and its deps

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hi everyone,
Today, we have released a new update of pki-core and its dependencies.
PKI 10.6.7 is now available upstream:
https://github.com/dogtagpki/pki/releases/tag/v10.6.7Tomcatjss 7.3.6 is
now available upstream:
https://github.com/dogtagpki/tomcatjss/releases/tag/v7.3.6
Fedora 28 builds are available via the following update:pki-core,
nuxwdog, dogtag-pki: 
https://bodhi.fedoraproject.org/updates/pki-core-10.6.7-1.fc28%20nuxwdog-1.0.5-2.fc28%20dogtag-pki-10.6.7-1.fc28tomcatjss:
 https://bodhi.fedoraproject.org/updates/FEDORA-2018-5558d54d37
Fedora 29 builds are available via the following update:pki-core,
nuxwdog, dogtag-pki, tomcatjss:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-fd68715f9c
Rawhide builds are available in Koji.
Fedora 27 builds are available in this COPR repository:
https://copr.fedorainfracloud.org/coprs/g/pki/10.6/
Regards,Dinesh
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Decommisioning gerrithub & jenkins services as of 09/21/2018

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Greetings PKI devs,
I just wanted to send out a follow-up reminder. We will be
decommisioning Gerrithub and Jenkins as of today (09/21/2018). We have
documented detailed steps to make the switch to Github PR and is
available here: http://www.dogtagpki.org/wiki/GitHub_Pull_Request 
Please feel free to reach out in case of any questions.
Regards,Dinesh
On Fri, 2018-09-07 at 12:08 -0400, Dinesh Prasanth Moluguwan
Krishnamoorthy wrote:
> Hello PKI developers,
> 
> First, I would like to thank everyone for your contributions to the
> PKI project. As a PKI team, we strive our best to keep the project
> clean, tidy and functional. Implementing CI and gerrithub (for code
> review) were some of the steps taken to keep the patch submission
> easy & clean. A bot (hosted on jenkins) was created to post comments
> to the patch you submitted on Gerrithub.
> 
> However, we decided to decommision Gerrithub and Jenkins as of
> 09/21/2018 (Friday) and move to Github Pull Requests.  Jenkins will
> be shutdown on 09/21/2018 and you'll not be receiving comments (or
> required acks) to your submitted patches.
> 
> The primary reasons for the decommission are:
> * Easier to track issues and commits since our upstream project is
> hosted on Github
> * Easier to review changes 
> * Reliable CI results on single patch with multiple commits
> * The extra effort to maintain these infrastructures
> 
> You can read more about gerrit vs github PR here: 
> http://www.dogtagpki.org/wiki/Gerrit_vs_GitHub_Pull_Request
> 
> It takes a few steps to submit your patch as a PR. The step-by-step
> instructions to submit patches via Github Pull Request is available
> here: http://www.dogtagpki.org/wiki/GitHub_Pull_Request
> 
> If you have any concerns with this decommission, please feel free to
> reach out.
> 
> Regards,
> Dinesh
> 
> 
> 
> 
> ___Pki-devel mailing
> listpki-de...@redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

Re: [Pki-devel] Decommisioning gerrithub & jenkins services as of 09/21/2018

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hi Trevor Vaughan,
Github is probably one of the most commonly used SCM for open-source
projects. Though Github itself isn't opensource, it doesn't affect PKI
as opensource project. We are not tied to github in anyway and it's
just a platform that we decided to be the best to use at the current
moment. 
However, we do have gitlab repo (mirrored) already: 
https://gitlab.com/dogtagpki/pki/ . This repo is setup as pull
mirroring.
Regards,Dinesh
On Fri, 2018-09-07 at 12:13 -0400, Trevor Vaughan wrote:
> Interesting, is there any insight on why you decided to go with a
> closed source platform instead of a FOSS one, like GitLab?
> On Fri, Sep 7, 2018 at 12:09 PM Dinesh Prasanth Moluguwan
> Krishnamoorthy  wrote:
> > Hello PKI developers,
> > First, I would like to thank everyone for your contributions to the
> > PKI project. As a PKI team, we strive our best to keep the project
> > clean, tidy and functional. Implementing CI and gerrithub (for code
> > review) were some of the steps taken to keep the patch submission
> > easy & clean. A bot (hosted on jenkins) was created to post
> > comments to the patch you submitted on Gerrithub.
> > However, we decided to decommision Gerrithub and Jenkins as of
> > 09/21/2018 (Friday) and move to Github Pull Requests.  Jenkins will
> > be shutdown on 09/21/2018 and you'll not be receiving comments (or
> > required acks) to your submitted patches.
> > The primary reasons for the decommission are:* Easier to track
> > issues and commits since our upstream project is hosted on Github*
> > Easier to review changes * Reliable CI results on single patch with
> > multiple commits* The extra effort to maintain these
> > infrastructures
> > You can read more about gerrit vs github PR here: 
> > http://www.dogtagpki.org/wiki/Gerrit_vs_GitHub_Pull_Request
> > It takes a few steps to submit your patch as a PR. The step-by-step 
> > instructions to submit patches via Github Pull Request is available
> > here: http://www.dogtagpki.org/wiki/GitHub_Pull_Request
> > If you have any concerns with this decommission, please feel free
> > to reach out.
> > Regards,Dinesh
> > 
> > 
> > 
> > 
> > ___
> > 
> > Pki-devel mailing list
> > 
> > Pki-devel@redhat.com
> > 
> > https://www.redhat.com/mailman/listinfo/pki-devel
___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel

[Pki-devel] Decommisioning gerrithub & jenkins services as of 09/21/2018

[Dinesh Prasanth Moluguwan Krishnamoorthy]

Hello PKI developers,
First, I would like to thank everyone for your contributions to the PKI
project. As a PKI team, we strive our best to keep the project clean,
tidy and functional. Implementing CI and gerrithub (for code review)
were some of the steps taken to keep the patch submission easy & clean.
A bot (hosted on jenkins) was created to post comments to the patch you
submitted on Gerrithub.
However, we decided to decommision Gerrithub and Jenkins as of
09/21/2018 (Friday) and move to Github Pull Requests.  Jenkins will be
shutdown on 09/21/2018 and you'll not be receiving comments (or
required acks) to your submitted patches.
The primary reasons for the decommission are:* Easier to track issues
and commits since our upstream project is hosted on Github* Easier to
review changes * Reliable CI results on single patch with multiple
commits* The extra effort to maintain these infrastructures
You can read more about gerrit vs github PR here: 
http://www.dogtagpki.org/wiki/Gerrit_vs_GitHub_Pull_Request 
id="-x-evo-selection-start-marker">
It takes a few steps to submit your patch as a PR. The step-by-step
instructions to submit patches via Github Pull Request is available
here: http://www.dogtagpki.org/wiki/GitHub_Pull_Request
If you have any concerns with this decommission, please feel free to
reach out.
Regards,Dinesh



___
Pki-devel mailing list
Pki-devel@redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel