One of our queue managers certificate is about to expire, it is been advised that renewing it is much cheaper than replacing the old one. These are the below steps which we are following(Through IBM Key Management):
Choose the personal certificate and select re-create - Renewal.csr
Send the Renewal.csr to CA for COMODO certificate - RenewedComodo
Choose the personal certificate and select Receive to import RenewedComodo. ( Refresh Security )
When creating a new certificate we opt for Personal Certificate Request and select new.This is the first step. and we follow the 2 and 3 steps.
Here is my query, other than selecting the re-create, there is no difference I had set up.
When I have two certificates as RenewalCOMODO and oldCOMODO, how do queue manager knows which is righteous.?
If it selects which is not expired, won't it be having the expired one in the database?
If we need to delete the old one, after adding the renewed one, How will it be different from replacing the certificates?
This will require a little background before getting to the answers.
When you initially created the CSR what you actually got was a public/private key pair and a Certificate Signing Request or "CSR". The CSR contains the public key and the requested attributes such as Distinguished Name. The CSR is signed with your private key so that any recipient can use the embedded public key to validate that the CSR and the requested attributes have not been tampered with.
What is less well known is that the CA is not bound to apply all the attributes that were provided in the CSR. For example, if the certificate purchased is a Domain Validated certificate and the CSR contains values for the OU field, the CA will simply delete them leaving only the DN and SAN fields plus their own information. Thus the certificate you get back may have different fields than the original CSR.
When you recreate the CSR from an in-use certificate the same process occurs again except that new CSR reflects any changes that the CA made originally. Close inspection of the original CSR and the newly generated one commonly show differences in the SAN or that an email contact has been added to the DN. However, from the CA's point of view these differences are cosmetic.
With that in mind, let's look at the questions again.
When I have two certificates as RenewalCOMODO and oldCOMODO, how do queue manager know which is right?
Assuming that you are talking about the artifacts the CA has provided after responding to the original and renewal CSR, the QMgr does not know which is which. You can run the receive command on either and, assuming both of them were signed by the same CA and use the same signer chain, either will work.
It is the administrator's responsibility to verify that the correct certificate is installed.
If it selects which is not expired, won't it be having the expired one in the database?
No. Each successful receive command keeps the private portions of the personal certificate and replaces the public portions. The label is associated with the private portion and this is checked for uniqueness so you cannot (or at least should not if there are no bugs) be able to have two copies in the same KDB.
If we need to delete the old one, after adding the renewed one, How will it be different from replacing the certificates?
Just make sure you receive the correct certificate. Always do a runmqakm -cert -details command or inspect the cert using the GUI.
Additional recommendations:
Always make a copy of the KDB before working on it.
Keep copies of your CSRs and certs in the KDB directory.
I like to use timestamps in the file names so it is obvious what the history was. My file names all start with YYYYMMDD like 20150908_QMName_CSR.arm and 20150908_QMName_CSR_signed.arm.
Make sure that the file permissions of the certificate files, KDB, and directory holding them are set to deny any access by anyone other than the MQM service account. If that's not possible, allow group access but make sure the members of the mqm group are as few as possible. Anyone who can read the certificates can use them. It is not necessary to know the password to the KDB to use the certs it contains.
When performing maintenance, I like to make a new copy of the KDB (with timestamped file name as described earlier) and when I'm sure it is ready I change the QMgr's SSLKEYR attribute to point to it. I then change the old file to be read-only and issue RESET SECURITY TYPE(SSL) on the QMgr.
Always remember to issue RESET SECURITY TYPE(SSL) on the QMgr. It is a rather disruptive command so try to not issue it when the QMgr is busy. It will require all channels to shut down and lots of reconnect attempts will prevent it from completing quickly.
Related
I have been managing Let's Encrypt's SSL certificates for a domain.
Now I am moving to Amazon API gateway. I will be using the AWS Certificate Manager to generate HTTPS certificates for the root domain and a bunch of subdomains.
If I make the transfer, what happens to my current HTTPS certificate which is associated with my domain. If browsers suddenly start seeing a new HTTPS certificate for a domain, for which they had been getting a different HTTPS certificate until now, would this be a problem?
Also, once I make the shift, what do I do with my current (manually managed) Let's Encrypt certificate? Is there a way to permanently void it?
Szabolcs Dombi says
You can have multiple valid certificates for the same domain at the
same time. Moving from one certificate issuer to another should not
cause a problem.
Toby Osbourn says
SSL certificates don’t last forever, most of them need to be renewed
on a yearly cycle and occasionally you will want to change the type of
the SSL certificate mid-cycle.
Since you are replacing certificates, I suggest you to back up the ones you have.
Once you have backed up the old certificates, just overwrite the .crt and .key files with your new ones. Then, reload your web server so it knows to look at these new certificates, and you should be good to go.
If it's within your interest to know more about how to Generate SSL certificate using Amazon Certificate Manager (ACM), I suggest Barguzar, A. (July 2018). Building Serverless Python Web Services with Zappa. where one can read a good step by step guide. See an excerpt of it below:
ACM is a service that manages and creates SSL/TSL certificates for
AWS-based services and applications. An ACM certificate works with
multiple domain names and subdomains. You can also use ACM to create a
wildcard SSL.
ACM is strictly linked with AWS Certificate Manager Private
Certificate Authority (ACM PCA). ACM PCA is responsible for validating
the domain authority and issuing the certificate.
You can have multiple valid certificates for the same domain at the same time. Moving from one certificate issuer to another should not cause a problem.
This also means that if you create a new certificate the old one still can be used unless it already expired.
For a long time I have been using "makecert.exe" to create my own certificate used for WCF communication between two clients.
Now and then I get error reports from users which have a higher security/validation procedures and errors are raised like this:
UntrustedRoot: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider
Now, I want to get rid of this and purchase a certificate. Preferably with a very long expiration date. But the questions are;
what type of certificate do I need? (what is the name of the certificate type)
where can I buy this? I would appreciate at least one line so I can verify certificate type as well.
I am importing X509 from PKCS #12 file (using PFXImportCertStore Cryptographic API) in Computer's Personal Store.
Problem:
Any process running under "Local Service" account or any non-admin account can not access privates key (restricted to Admin user by Windows).
How to give access to private keys of a certificate to non-admin users and local service?
Note:
Since multiple process use certificates, I preferred using Computers store instead user's store.
This is a tricky one with some pitfalls. I had the same problem and was close to despair, when I finally found the remark which saved me in this post
I succeeded to do this for a local service running under the Network Service account.
First, there is the option to grant other users access to the private key of a certificate in the MS certificate store. Already this I'd classify as druid knowledge: this option is available in the context menu (right click the certificate), but only if the certificate resides in the localMachine\Personal store. There, in the entry All tasks, you will find the sub entry Manage Private Keys. This is not available in other stores, not even in the CurrentUser\Personal store.
This entry opens a dialog which allows you to add access rights to the certificate for other users. Here, the next hurdle waits for you: the default setting is to search for users in the domain, not on the local machine. The desired user may not be found, unless you change the search filter.
To this result I came very fast by googling, but it did not help. I could get the service to run, but only if I changed the service user to the logon account, which is not what I wanted (this leads, btw, to a workaround: create a local user account for services and import the certificate from within that user account. You can then place the certificate in almost any store and it will work fine)
This is where the post cited above comes in, the last hurdle for me: the procedure described above seems to work only if you import the certificate into the certificate store from within the MMC snapin. Select the store localMachine\Personal and use the context menu to import the certificate in question. (I chose to make the private key exportable, this may or may not be relevant here). If you import the certificate by double clicking on it in the file system, it will be imported into some store in the Current User location. I used to do this and then move it into the localMachine\Personal folder and changed the access right -- this did never work for me. Only after importing it from within localMachine\Personal in the MMC certificate snap-in it worked immediately...
(Also note that you have to place the certificate into a store which can be found by the service user. Your current user stores usually does not allow this, so localMachine is the better choice, anyway)
I don't know whether you can move the certificate around afterwards, but that's easy to check in the system..
I have set up the following self-signed certificates on Mac OS X 10.6.8 and made them trusted in Keychain Access:
*.la.com *.la.mx *.la.es
*.la.ca *.la.com.ar *.la.co.nz
*.la.us *.la.co.uk
However, for a reason that I can not understand the *.la.us certificate can not be trusted even though I follow the exact same process in creating it and trusting it. In fact, if I do not trust and then trust each of the certificates they work and I get a green pad lock in Chrome 43.0.2357.132 (64-bit) "except" for the *.la.us.
For *.la.us I get:
Your connection is not private
Attackers might be trying to steal your information from www.la.us (for example, passwords, messages or credit cards). NET_ERR_CERT_COMMON_NAME_INVALID
If I click on Advanced I see:
This server could not prove that it is www.la.us; its security certificate is from *.la.us. This may be caused by a misconfiguration or an attacker intercepting your connection.
If I proceed and click on the red padlock I see:
Server's certificate does not match the URL.
How is it the server's certificate does not match the URL when it clearly tells me it's www.la.us and the certificate is for *.la.us?
Is there something special about the domain la.us? I have re-created the cert several times, re-entered the MAMP Apache virtual conf several times, and tried Keychain Access again and again (removing the cert in between). Any thoughts anyone?
There are special rules for domains inside the .us name space and it looks like Chrome is enforcing these. From the Wikipedia entry for .us:
A two-letter second-level domain is formally reserved for each U.S. state, federal territory, and the District of Columbia....
These rules also reflected in the public suffix list where you find special entries for la.us and also various subdomains like k12.la.us.
These special rules suggest that there is no single owner of the *.la.us namespace and thus you should not be able to get a wildcard certificate for *.la.us. This is similar to the uk and co.uk namespaces where you can not get certificates for *.co.uk but only for *.la.co.uk. Note that not all of the rules in the public suffix list are used by all browsers to check the subject of the certificates.
Is there a way to choose the specific default client certificate for authentication on web-resources? In the prefs.js in firefox app data folder, there is a line:
security.default_personal_cert
I changed its value to:
Select Automatically
And now it is selecting the first certificate for site avaliable. I want basically to automatate this process (with imacros and few other tools). Is there a way i can set a SPECIFIC certificate as default client certificate? Maybe i have missed somethign else?
It is possible to implement this, but probably not very useful, and I do not believe it is implemented in Firefox.
Servers are usually configured with a specific CA certificate (or set thereof) to use for validating client certificates. The TLS Certificate Request message will usually advertise the Issuer Distinguished Names of these CA certificates in the certificate_authorities field, which the client will then use to select an appropriate certificate to supply in the Client Certificate message. In particular:
If the certificate_authorities list in the certificate request
message was non-empty, one of the certificates in the certificate
chain SHOULD be issued by one of the listed CAs.
An "always use this certificate" option would be useful only in the case where the server does not advertise which CA(s) it intends to use to validate client certificates (I have never seen this situation before). Normally, the Select Automatically heuristic will Do The Right Thing.
If you need an automated way to choose a particular certificate where you have multiple certificates for the same site, Firefox provides the option of multiple profiles. You can have a single certificate in each profile, which will be automatically chosen. It is inconvenient but I do not know of another way.