Re: Pkcs
Mirthe Luria
Hi everyone, I used Certbot on a Centos 8 server to create and install a Lets Encrypt certificate on one of the sites hosted on that server, there are 5 sites, one site uses a certificate from another provider while the other 4 they use Lets Encrypt, so far coexistence is OK.
Now I would like to use my UTM to add an extra layer of security by configuring reverse proxy but it asks me to load PKCS # 12.
How can I generate this file considering that the certificate was generated with Certbot?
The fullchain.pem and privkey.pem files created by certbot can be converted to PKCS#12 format.
OpenSSL is one software that can be used to do that quite easily, with:
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out domain.pfx
Where did you install Firefox from? Help Mozilla uncover 3rd party websites that offer problematic Firefox installation by taking part in our campaign. There will be swag, and you'll be featured in our blog if you manage to report at least 10 valid reports!
I am using Firefox for Linux, and whenever my yubikey is plugged in, firefox will start bothering me for a pkcs#11 password. It always happens on start-up but it gets relentlessly annoying if I happen to be on a site which potentially utilizes certificate auth, which I do not use this yubikey for.
It's ridiculous for firefox to be automatically importing and re-adding random security devices from my system without giving me the ability to disable firefox from excluding devices, and a security risk to do so.
The issue is with firefox, not my yubikey. Firefox detects a device with pkcs#11 capabilities, assumes that I must want to use it no matter what, then spams me pop-ups to log in with it. I have not found a config option to ignore specific capabilities for a securty device.
Firefox is enumerating all my devices and has determined that the yubikey has smart card capabilities, which it does, but I have no intention of using them in firefox. I am only using the TOTP features of yubikey in firefox.
I solved this by disabling it in the opensc config. I did notice if I unload the p11kit-proxy node in the settings that it keeps coming back. It seems that by default p11-proxy kit it is loaded into every nssdb on the system.
I would categorize it as a firefox bug that the p11-proxy-kit section that I am clicking "unload" on in firefox settings gets reloaded without my consent, but at least I have a workaround by disabling it in opensc.
On the Security Devices Page (Which you can find by clicking on settings and then searching for "Security Devices"), find the OpenSC library and then click unload. This will remove it until you manually re-add the library.
The enterprise policy "SecurityDevices" lets you delete devices, it only requires a policies.json file in the installation path. Visit about:policies in the address bar for more details.
The Java platform defines a set of programming interfaces for performing cryptographic operations. These interfaces are collectively known as the Java Cryptography Architecture (JCA) and the Java Cryptography Extension (JCE). See Java Cryptography Architecture (JCA) Reference Guide.
The cryptographic interfaces are provider-based. Specifically, applications talk to Application Programming Interfaces (APIs), and the actual cryptographic operations are performed in configured providers which adhere to a set of Service Provider Interfaces (SPIs). This architecture supports different provider implementations. Some providers may perform cryptographic operations in software; others may perform the operations on a hardware token (for example, on a smartcard device or on a hardware cryptographic accelerator).
The Cryptographic Token Interface Standard, PKCS#11, is produced by RSA Security and defines native programming interfaces to cryptographic tokens, such as hardware cryptographic accelerators and smartcards. Existing applications that use the JCA and JCE APIs can access native PKCS#11 tokens with the PKCS#11 provider. No modifications to the application are required. The only requirement is to properly configure the provider.
Although an application can make use of most PKCS#11 features using existing APIs, some applications might need more flexibility and capabilities. For example, an application might want to deal with smartcards being removed and inserted dynamically more easily. Or, a PKCS#11 token might require authentication for some non-key-related operations and therefore, the application must be able to log into the token without using keystore. The JCA gives applications greater flexibility in dealing with different providers.
This document describes how native PKCS#11 tokens can be configured into the Java platform for use by Java applications. It also describes how the JCA makes it easier for applications to deal with different types of providers, including PKCS#11 providers.
The SunPKCS11 provider, in contrast to most other providers, does not implement cryptographic algorithms itself. Instead, it acts as a bridge between the Java JCA and JCE APIs and the native PKCS#11 cryptographic API, translating the calls and conventions between the two.
The SunPKCS11 provider requires an implementation of PKCS#11 v2.20 or later to be installed on the system. This implementation must take the form of a shared-object library (.so on Solaris and Linux) or dynamic-link library (.dll on Windows or .dylib on macOS). Consult your vendor documentation to find out if your cryptographic device includes such a PKCS#11 implementation, how to configure it, and what the name of the library file is.
The SunPKCS11 provider supports a number of algorithms, provided that the underlying PKCS#11 implementation offers them. The algorithms and their corresponding PKCS#11 mechanisms are listed in the table in SunPKCS11 Provider Supported Algorithms.
To use more than one slot per PKCS#11 implementation, or to use more than one PKCS#11 implementation, simply repeat the installation for each with the appropriate configuration file. This will result in a SunPKCS11 provider instance for each slot of each PKCS#11 implementation.
At most, you can specify one of enabledMechanisms or disabledMechanisms. If you specify neither, then the mechanisms enabled are those that are supported by both the SunPKCS11 provider (see SunPKCS11 Provider Supported Algorithms) and the PKCS#11 token.
The attributes option allows you to specify additional PKCS#11 attributes that should be set when creating PKCS#11 key objects. By default, the SunPKCS11 provider only specifies mandatory PKCS#11 attributes when creating objects. For example, for RSA public keys it specifies the key type and algorithm (CKA_CLASS and CKA_KEY_TYPE) and the key values for RSA public keys (CKA_MODULUS and CKA_PUBLIC_EXPONENT). The PKCS#11 library you are using will assign implementation specific default values to the other attributes of an RSA public key, for example that the key can be used to encrypt and verify messages (CKA_ENCRYPT and CKA_VERIFY = true).
The attributes option can be used if you do not like the default values your PKCS#11 implementation assigns or if your PKCS#11 implementation does not support defaults and requires a value to be specified explicitly. Note that specifying attributes that your PKCS#11 implementation does not support or that are invalid for the type of key in question may cause the operation to fail at runtime.
The attribute names and values are specified as a list of one or more name-value pairs. name must be a CKA_xxx constant from the PKCS#11 specification, for example CKA_SENSITIVE. value can be one of the following:
If the attributes option is specified multiple times, the entries are processed in the order specified with the attributes aggregated and later attributes overriding earlier ones. For example, consider the following configuration file excerpt:
The first entry says to specify CKA_SIGN = true for all private keys. The second option overrides that with null for Diffie-Hellman private keys, so the CKA_SIGN attribute will not specified for them at all. Finally, the third option says to also specify CKA_DECRYPT = true for RSA private keys. That means RSA private keys will have both CKA_SIGN = true and CKA_DECRYPT = true set.
There is also a special form of the attributes option. You can write attributes = compatibility in the configuration file. That is a shortcut for a whole set of attribute statements. They are designed to provider maximum compatibility with existing Java applications, which may expect, for example, all key components to be accessible and secret keys to be usable for both encryption and decryption. The compatibility attributes line can be used together with other attributes lines, in which case the same aggregation and overriding rules apply as described earlier.
Network Security Services (NSS) is a set of open source security libraries whose crypto APIs are based on PKCS#11 but it includes special features that are outside of the PKCS#11 standard. The SunPKCS11 provider includes code to interact with these NSS specific features, including several NSS specific configuration directives.
The SunPKCS11 provider uses NSS specific code when any of the nss configuration directives described in Table 5-2 are used. In that case, the regular configuration commands library, slot, and slotListIndex cannot be used.
This is the full path name of the directory containing the NSS and NSPR libraries. It must be specified unless NSS has already been loaded and initialized by another component running in the same process as the Java VM.
Note: Depending on your platform, you may have to set the environment variable LD_LIBRARY_PATH (Linux), PATH (Windows), or DYLD_LIBRARY_PATH (macOS) to include this directory to enable the operating system to locate the dependent libraries.
59fb9ae87f