I see the following output after creating a key with HashiCorp vault’s transit engine using vault write -f transit/keys/transit_key exportable=true command-
...
“lease duration”: 0,
“lease_id”: “”,
“renewable”: false
...
Does this mean that the key is valid for infinity?
Yes: a lease duration (for some secret and authentication engines a TTY) of 0 indicates no expiration for the generated secret, authentication token, etc.
Related
I am trying to generate X509 certificates in C# code (using the class X509Certificate2) and upload these certificates to an Azure Key Vault. When I try to upload them (programmatically or via the Azure Portal in a browser), I get the following error message:
The specified X.509 certificate content is invalid. Error: one or more x.509 properties are invalid.
How can I debug what is wrong with my certificate generation? Is it documented what combinations of X509 properties are acceptable? If so, where can I read about it?
Output from certutil -dump foo.pfx:
> certutil -dump E:\Raven\Certificates\test2.pfx
Enter PFX password:
================ Certificate 0 ================
================ Begin Nesting Level 1 ================
Element 0:
Serial Number: 86ae932f199f419115e8087f3f0cb6df747bd2adf966d46aab194f4283849635
Issuer: CN=intermediate CA
NotBefore: 24-01-2022 11:22
NotAfter: 25-01-2022 11:22
Subject: O=foo, CN=bar
Non-root Certificate
Cert Hash(sha1): a700464f1708cec627eabcd007ef574d1f0fc140
---------------- End Nesting Level 1 ----------------
Provider = Microsoft Software Key Storage Provider
Private key is NOT plain text exportable
Signature test passed
CertUtil: -dump command completed successfully.
In my case it turned out to be two things:
The serial number. I was using RandomNumberGenerator.GetBytes(32) to generate serial numbers, which was apparently bad. The vault is happier if I do Guid.NewGuid().ToByteArray().
The flags (enum X509KeyUsageFlags). I tested several combinations of flags, and it turns out that whenever I use the flag X509KeyUsageFlags.KeyEncipherment the vault will reject the certificate.
I don't know why. I suppse that if you use the KeyEncipherment flag, there is some other invariant that the certificate needs to obey.
In any case, when I fix the serial numbers and remove this flag, it appears that the vault accepts my certificates.
If I fix only the serial number but keep the KeyEncipherment flag, I get this error message:
Unsupported key operation(s): "wrapKey", "unwrapKey". Supported values are "sign", "verify".
I am working on OIOSAML with ADFS 2.0. I need the IdP response to be signed as well as encrypted. Below is my understanding on how signing and encryption of SAML request and response works:
SP signs the request using its own certificate key (Key-1)
IdP verifies the request using SP's public key (Key-1)
IdP signs the response using its own certificate key (Key-2)
IdP encrypts the response assertion using certificate key provided by SP (Key-3)
SP verifies response using IdP's public key (Key-2)
SP decrypts the response assertion using its own private key (Key-3)
If I keep Key-1 and Key-3 same, everything works. As my keystore in OIOSAML has only one key.
But now I want to use separate keys for request signing and response encryption. It fails here.
Does OIOSAML support multiple keys in keystore?
If yes then how does it distinguish between signing and encryption keys?
This feature is available from OIOSAML release 3.
I cannot successfully generate a signature for making AWS Requests using PAW.
Here is a link to the signature I am attempting to generate: http://docs.aws.amazon.com/AWSECommerceService/latest/DG/HMACSignatures.html#HMACAuth_ItemsRequired
I have already searched other StackOverflow posts such as: Paw rest client : how to compute HMAC-SHA256 using absolute url as input
To answer your precise question about HMAC-SHA256 signatures, here's a code snippet that will work to compute this specific type of signature, returning the result Base 64 encoded in Paw (it uses the HMAC Dynamic Value programmatically):
function signHmac256(input, key) {
var dv = DynamicValue("com.luckymarmot.HMACDynamicValue", {
input: input,
key: key,
algorithm: 3 /* = SHA256 */,
uppercase: false /* keep hashes lowercase */,
encoding: 'Base64' /* encode hash data in base 64 */,
});
return dv.getEvaluatedString();
}
Otherwise, about the AWS Product Advertising API, we've made a dynamic value for it just today (which is a good opportunity for use to showcase the extension API), see AWS Product Advertising API Auth for Paw and the GitHub Repository here.
To use this dynamic value, first install it through the link shared above, then you can set up all other parameters and then enter a Signature parameter, and set this dynamic value as its value:
Open the token to enter your AWS Secret Key (used in the HMAC signature):
How I get the following 3 Test credentials to setup sandbox
MID (merchant_id)
Secure key (used to determine hash)
Secure key id (merchant_key_id)
I got payzippy php-sdk from below mention URL but need test credentials to run this example to understand it.
https://github.com/payzippy/php-sdk
For the merchant id and secret key, you will have to reach out to us at 080-49697070 or contactus#payzippy.com. We will generate one for you and also assist you with the other processes.
Happy to Serve!
Team Payzippy.
I have installed the openldap version 2.4.23 on windows xp and using the apache DS as a client.I can authenticate users on a client server I set up for testing.
My next step is to turn on a password policy. This is where things have gotten a bit hazy for me and I'm hoping someone can help me out.
i added a password policy also by using the followin command
ldapadd -x -c -f -D "cn=Manager,dc=maxcrc,dc=com" -w secret
but after addition of password policies how do i make them in effect.
The openldap documentation says the password policy module should be configured with the DN of the default policy.
i added the following lines in slapd.conf file
# invokes password policies for this DIT only
overlay ppolicy
# Default ppolicy
ppolicy_default "cn=passwordDefault,ou=policies,dc=maxcrc,dc=com"
but somehow it is not getting loaded , i have already spent more a lot of time on this, but i am not getting the proper guide for the same.
Can anyone shed some light on this in plain, layman's terms?
Thanks in advance.
My ldif file is as follows.
dn: cn=passwordDefault,ou=policies,dc=localdomain,dc=com
objectClass: pwdPolicy
objectClass: person
objectClass: top
cn: passwordDefault
sn: passwordDefault
pwdAttribute: userPassword
pwdCheckQuality: 1
pwdMinAge: 1
pwdMaxAge: 90
pwdMinLength: 6
pwdInHistory: 4
pwdMaxFailure: 3
pwdFailureCountInterval: 0
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdAllowUserChange: TRUE
pwdExpireWarning: 604800
pwdGraceAuthNLimit: 3
pwdMustChange: TRUE
pwdSafeModify: TRUE
after adding this policy and restarting the server i tried changing the password of existing as well as newly added users.
The server allows me to change the password to a string with length less than 6
whereas i have mentioned pwdMinLength: 6 in ldif.
as well as i tried changing the password more than once , but it allows me to change the password to recently used password, whereas the pwdInHistory: 4 in ldif.
The password policy doesn't work if you use the rootDN to execute the updates. You must use an existing admin account, or the user's own account.
It is not clear how you are setting the password when testing, but I would check if you are passing the password in the correct format, meaning that the server needs to receive the password in cleartext. Some clients would hash the value before sending the value to the OpenLDAP server, in which case it would be impossible for the OpenLDAP server to determine the length of password. The communication can and should be encrypted, but it shouldn't be pre-hashed. Hashing can be handled by the server:
pwdCheckQuality
If the value is 1 and the supplied password is in cleartext then a user supplied function (defined using the pwdCheckModule - if defined - will be called to check the password quality. If this function is not available then the password will be accepted (assuming it passes all the other tests defined by the various pwdPolicy attributes).
reference: http://www.zytrax.com/books/ldap/ch6/ppolicy.html
the rootdn bypass password policy, so do not use rootdn in your
ldappasswd command.
https://www.openldap.org/lists/openldap-technical/201102/msg00262.html
You can basically put any password (not empty thou) if setting passwords using ldappasswd and binding with rootdn.
It's a bit tricky situation since you cannot change the password with "passwd" command either for the user. In this case the password policy would kick in.
If you know the rootdn password, you can bypass everything.