There are two separate CA virtual machines (Windows Server 2012):
RootCA
SubCA - created/signed by RootCA
RootCA is off and offline (no network connectivity).
How to renew Microsoft SubCA?
SubCA is valid for more than a year now, but we want to plan ahead.
Root and Sub CAs are not connected to Windows domain, it is not for used for Active Directory.
SubCA is used to generate SSL certificates for out internal servers - Apache, Nginx, IIS, etc.
RootCA and SubCA certificates are trusted on Windows and Linux machines (both servers and workstations).
Is it necessary to add newly renewed SubCA certificate as trusted after renewinig it? Or it will be already trusted, but now it is just renewed?
The renewed SubCA will be trusted as it will be signed by the already trusted RootCA - that's how PKI works.
Never add the new SubCA certificate into your trust-store as it mustn't be explicitly trusted. It is only implicitly trusted because it's issuing CA (the Root in this case) is trusted. Remember that if you were to add it to the trust-store and you subsequently decided that the SubCA was compromised and therefore required revoking, you would have to manually remove it from all trust-stores - a laborious process.
Instead, you will need to give all subscribers this new SubCA certificate when you next renew their end-entity certificate so that they present the correct chain when relying parties connect (as required by the TLS protocol).
In the Windows world you can add it to the Intermediate CA store (not the Root CA store remember!) so that servers have it to hand when their end-entity certificate is renewed by the Sub CA. Windows will figure out which CA certificate to send when the end-entity certificate is renewed.
In the non-Windows world you have to read the documentation for the application to ascertain where the CA certificates should be installed. Quite often, they are appended to the file containing the end-entity certificate, but it can vary - so do check.
Related
When I use self-sign certificate, I made a self-CA.cer and a server.cer, server.cer is for web service and self-CA.cer is added in client code. When I check certificate , I check if server.cer is from this self-CA.cer, right?
But, if I buy a CA certificate, what I only got is a server.cer generated from CA, right? and CA certificate can generate many server.cer, and they are all trusted , what I got is one from these .
In my client code, others said I only need to change my http to https, that's it ,after I buy CA. but how can I distinguish which server certificate is from my own server? I only want trust the server certificate from my own server.
if I buy a CA certificate
you can't buy a CA certificate (with small exception, which is not your case). You are purchasing an end-entity certificate which cannot be used to sign other certificates. It is controlled by a Basic Constraints certificate. Any standard validation code will reject any certificate that is signed by non-CA certificate due to Basic Constraints extension value (isCA attribute is set to False).
RFC 5280 -- Basic Constraints
If you trust a CA you trust all certs they issue (unless expired or revoked) -- that's how PKI works.
If that CA issues certs to other sites/servers, and you make HTTPS (or otherwise SSL/TLS or DTLS) connections to those other sites/severs, you will trust their certs and thus trust them.
But if you mean you want to trust only the specific cert issued to your server for your server, that's automatic. The cert issued to your server has your domain name in it, while the certs issued to other servers have their (different) names, and an HTTPS client like a browser will only trust a cert that is issued by a trusted CA and has the correct server name in it, so it will trust only your cert for your server, and will trust other certs only for the other servers those certs are issued to.
For much more detail, see Stack's Great Ursine Epic https://security.stackexchange.com/questions/20803/how-does-ssl-work/
I have read through this post on signing a PowerShell script with a certificate. This is more on using external certificate from VeriSign (or similar) to encode and protect the code I have developed within a PowerShell script.
I am just trying to find out if this will actually work. I would expect the process to go as:
Purchase code-signing certificate from VeriSign
Install certificate on my computer
Sign the PowerShell script
Execute the script on desired device
Since this script would be signed with a external CA wouldn't Windows be able to authenticate the certificate since Windows trust VeriSign root CA? My guess would be since Windows has the root CA for VeriSign already and trust it, if I happen on a system that does not allow Internet access that the certificate will still be verified and allow me to run it?
That should work. I've never tried it, though, but your logic makes sense.
I looked at the cert store on my Win7 machine and it has an Oracle code signing cert issued by "Verisign Class 3 Code Signing 2010 CA". That CA is an intermediate CA. The root CA is "Verisign Class 3 Public Primary Certification AUthority - G5". That root CA is in Windows trusted root CA store. So what I gather from this is:
That yes you can do it - Oracle does it
Verisign does issue code signing certs, but they are signed with an intermediate CA.
This means Windows has to obtain this cert somehow. The Verisign
intermediate cert does have the "Authority Info Access" field which
is one way Windows can retrieve an intermediate cert. But the
machine would have to be able to access the internet.
An alternative (if internet access isn't available) is to install the intermediate cert on your users' machines. Could be part of an installer. I think that must be what Oracle did on my machine
For an Authenticode EXE, another alternative (if machine can't access
internet) is to make sure intermediate cert was embedded in the
authenticode signature in the EXE. However I don't know if
Powershell would support that.
As another confirmation you could call/email Verisign to verify their support.
Executing the script on desired device still requires you to set the execution policy to at least AllSigned on that device. And you will still get a question if you want to trust this publisher, unless you add the certificate to the device or the domain. See here.
I have this weirdest problem. First off: I'm VERY new to this certificate thingy. I've done a fair amount of searches and reading up though.
The CA Cert that I install into the Trusted Root Certificate
Authorities store in my server automatically get removed/disappeared
as soon as a client web-browser try to connect to a web-site using an
SSL cert created with that CA cert.
DETAILS:
Windows Server 2008 R2 (development server).
I've created my own Certificate Authority Cert; which I use it to generate an SSL server cert (to install on my IIS 7 Server) and a client cert (for use at my local PC to connect to the WCF Webservice on the development server which is set to Require SSL and Require Client Cert).
I installed the CA Cert into the Trusted Root on both Server and local PC.
Installed the SSL server cert into the IIS7 for that particular site and did the https binding to port 443.
As soon as I launch my browser to access that site with HTTPS, the CA
cert in automatically removed on the server (from the Trusted Root
Certificate Authorities store). and my local PC browser will report
an error 403.
This is driving me nuts... anyone knows what is happening?
Apparently, after a lot of running around, it is due to too many of the same certs in many stores.
I open the MMC.exe > Add/Remove SnapIns > Certificates
Notice there are 3 types there (My User Account, Service Account & Computer Account).
Open up My User and Computer Account, go through all the stores for each one and DELETE all of the CA cert with the same name. Then add the CA cert in either My User Account or Computer Account, depending on how you access the certs (in the event of the cert being used programatically, install it in the Computer Account, [Trusted Root Certificate Authorities].
Just 1 place, then the problem will dissappear.
I'm not clear about the authorization of certificate: a website has been associated with a certificate, say https://test.mysite.com. Do I have to install the certificate on my computer before access this url?
Another question is: every certificate is issued by a CA. If I have trusted a CA before by "installing" a cerficiate, will I trust the all the following certificates issued by the same CA?
Thanks!
It depends on the library or browser you are using to access to the URL but, if the certificate is issued by a trusted CA (one that your library or browser already trusts), the web site's certificate does not need to be installed before accessing the site.
If the CA is not trusted, there are two options. One is to trust the certificate. Browsing to the page will usually open a dialog where the user can choose to trust the certificate, for example. The second is to add the CA to the list of trusted CAs. On Windows, this is done by adding the CA's certificate to the "Trusted Root Authorities" certificate store. The latter case means any other certificate issued by the CA will also be trusted.
Hi all
why apple has given link of entrust ssl ,is it necessary ?
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingWIthAPS/CommunicatingWIthAPS.html
see at first note:
Note: To establish a TLS session with APNs, an Entrust Secure CA root certificate must be installed on the provider’s server. If the server is running Mac OS X, this root certificate is already in the keychain. On other systems, the certificate might not be available. You can download this certificate from the Entrust SSL Certificates website.
Yes, the certificate is necessary to establish a TLS session with APNs.
But you don't need to buy a certificate from Entrust. (I guess this was what you thought, because there are huge $xxx for a certificate boxes on the Entrust website)
The APNs uses a secure connection to a server that uses a certificate from Entrust. And this connection would fail when the CA root certificate wouldn't be installed on your computer. All "regular" certificates are only valid if the root certificate is known to your computer. And this is the file that they want you to download.
But most likely the Entrust Secure CA root cert is already installed. I used APNs from Ubuntu, and Arch Linux, and I installed nothing from Entrust. This is from my arch install, all necessary root ca certificates are already there:
[root#dellbook certs]# ls /etc/ssl/certs/Entrust*
/etc/ssl/certs/Entrust.net_Global_Secure_Personal_CA.pem
/etc/ssl/certs/Entrust.net_Global_Secure_Server_CA.pem
/etc/ssl/certs/Entrust.net_Premium_2048_Secure_Server_CA.pem
/etc/ssl/certs/Entrust.net_Secure_Personal_CA.pem
/etc/ssl/certs/Entrust.net_Secure_Server_CA.pem
/etc/ssl/certs/Entrust_Root_Certification_Authority.pem
It appears that you don't have to buy one of the Entrust certificates; you just have to download the certificate authority certificate (which is free) from their website. Apple should have made this more clear. I found the current link to this, which may not work forever, but for now here it is: https://www.entrustdatacard.com/pages/root-certificates-download