-
-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem while revoking certificate #374
Comments
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
Mar 13, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. The exec for the crl renew was updated to clarify which server it's done for.
I've found the problem and am working on the solution |
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
Mar 13, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
Mar 13, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
Mar 13, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
Mar 14, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names. `catch_changes` in the acceptance test was taken out because a crl renew is triggrered which is seen as a change.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names. `catch_changes` in the acceptance test was taken out because a crl renew is triggrered which is seen as a change.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names. `catch_changes` in the acceptance test was taken out because a crl renew is triggrered which is seen as a change.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names. `catch_changes` in the acceptance test was taken out because a crl renew is triggrered which is seen as a change.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names. `catch_changes` in the acceptance test was taken out because a crl renew is triggrered which is seen as a change.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 18, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names. `catch_changes` in the acceptance test was taken out because a crl renew is triggrered which is seen as a change.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 20, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names. `catch_changes` in the acceptance test was taken out because a crl renew is triggrered which is seen as a change.
Rubueno
pushed a commit
to Rubueno/puppet-openvpn
that referenced
this issue
May 22, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names. `catch_changes` in the acceptance test was taken out because a crl renew is triggrered which is seen as a change.
bastelfreak
added a commit
that referenced
this issue
May 23, 2020
Fixes #374 - Revocation command update and crl renew
vanElden
pushed a commit
to vanElden/puppet-openvpn
that referenced
this issue
Nov 10, 2020
An issue was raised informing that the revocation command is incorrect. This was diagnosed to indeed be the case. As the `$name` variable in context of `revoke.pp` does not evalute to `server name` but instead `client name`. The exec for the crl renew was updated to clarify which server it's done for and to prevent duplicate `exec` resource names. `catch_changes` in the acceptance test was taken out because a crl renew is triggrered which is seen as a change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Affected Puppet, Ruby, OS and module versions/distributions
How to reproduce (e.g Puppet code you use)
Node with a simply
And the following hiera code
Application
What are you seeing
This initializes correctly the server and the client can connect without problem
Then I want to test revoking a certificate so I add
to hiera. With master code, I have the following error
I can fix this by changing revoke.pp line 51
But the easyrsa command is not correct
--batch option is a global option and must be place before the command so before revoke, the correct command is
No more error, but the renewal of the crl is not schedule
What behaviour did you expect instead
The corresponding certificate is revoked and the crl is regenerated.
Output log
Any additional information you'd like to impart
The text was updated successfully, but these errors were encountered: