Suppose we have the following situation: we have a machine, which acquired its ticket, then this ticket has been forwarded to another machine. Can that other machine renew the received ticket?
Other question - if the machine which acquired the ticket renew it, do other machines, which that ticket was forwarded to, have to renew this ticket by their own? or it gets immediately invalidated once the initial machine renews it?
The protocol (RFC 4120) permits a client to forward a renewable ticket.
All the implementations I'm familiar with (Windows, MIT and Heimdal) will end up with the ticket renewable once forwarded if it was forwarded before. So, you could do something like
ssh -K hostname # forward
kinit -R # renew tticket run inside ssh
Each ticket is its own thing. That is, the forwarded ticket is separate from the ticket before forwarding; the renewed ticket generated from the forwarded ticket is separate from the forward ticket. It's also separate from any renewed ticket generated from the base ticket.
So, renewing tickets doesn't really typically inviladitate them.
Each machine should be responsible for renewing its own tickets, and they should not cause problems for each other.
Related
We have a simple system with a REST service (WebAPI) that will be hosted on one machine (hosted on IIS on a custom port, port numer 3031) and with a website hosted on another machine that will be talking to the service.
We want both to use SSL, so as I understand we will need to purchase two separate SSL certificates for the production deployment on the Internet.
Does that sound right?
If so, then I don't know how do I request and purchase a certificate for the WebAPI REST service... The service will be hosted on a custom port 3031, should I purchase a normal certificate for the domain name of the machine where the service will be hosted? And then should I basically install the certificate on the IIS on that machine (like it's described here: https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/working-with-ssl-in-web-api).
How will I be able to perform a verification of the domain for the purchased certificate if I'm going to use the certificate for a REST service on a custom port? (not for a regular website).
Apologies for my ignorance, I have searched the forum to find an answer to my issue, but I didn't find one, maybe it's because my very limited knowledge about certificates and security.
I am currently struggling with an issue which I am now led to believe is being caused by IIS.
I am currently testing a self signed PKI setup with a Root CA (MyNewCA), two signed Client Certificates (certificate1, certificate2) and a Revocation list (revocationlist.crl) that is also signed by the CA.
I have added certificate1 to the revocation list and published it to a http port 80 site that exists on our network. I have then created a fake site (testsite) that is secured via a TLS certificate.
From a client machine, I have run the CertUtil commands on both certificate1 and certificate2 and these commands correctly access the http crl site, and recognise that certificate1 is revoked, and certificate2 is a legitimate non revoked certificate.
However, when I connect to the testsite via a client browser, and supply the invalid certificate - IIS still serves me the page instead of giving me a 403.13 error.
I have done a ton of reading, and it seems that at times there are CRL caching issues, however the first revocation list that I published had certificate1's serial number in it, and hence even a cached version will contain that revoked cert.
I have changed the CertCheckMode in RegEdit on the IIS server to the value 4 in an attempt to force IIS to fetch the latest crl on EVERY request, but even that setting is still allowing the revoked certificate to be served to the client.
The CRL itself has;
Effective date of 19th January 2016
Next update of 20th January 2017
I can provide the certutil output if it is useful, or any other log data that would help in pinpointing the problem.
I ran Fiddler on my client machine and verified that the crl was fetched from the Http site.
If anyone can provide any insight into this issue I would greatly appreciate it.
Thanks,
It is expected behavior. IIS do not prevent access to SSL sites even if there are revocation issues with the SSL cert. It is up to client what to do with the information it receives from the server. It is up to client to perform (or to not perform) revocation checking and to make decision about further steps.
In addition, make sure if client's cache has the most recent CRL.
I need to setup a cron job to run a SOAP client. The customer insists that I connect to their web service (on an https address) from an https address. They insist that if I don't their response to me can't be encrypted.
My first question is, is that true? I thought that as long as I'm connecting to their SOAP service over https, the response back would automatically be encrypted.
If that's true, how can I run a cron job to be as https? My site is on a LAMP setup with cPanel access.
Thank you in advance for your help!
Your customers statement seems to be a little bit unclear in what he/she specifically means by "... connecting from an https adress" as there isn't any notion of the term "https adress" in the specs and https URLS only seem to make sense in the context of Request-URI s given in a https request.
Given this unclarity I'm only wild guessing. Nevertheless to me it seems your clients requirements might most probably not be connected to the http protocol but rather to establishing your TLS connection.
If your client is very sensitive in respect to the security of his system - which in fact if he intends to offer RPC requests might be a very good idea - he might not want to the whole world to be able to connect an encrypted connection to his machines and rely on any secondary authentication mechanism once the connection has been established.
As most users of the public internet don't have any certificates signed by a trusted authority this feature it isn't used out in the open wild but besides server authentication the TLS handshake protocol also provides a means of client authentication via client certificates (the relevant part being section 7 in RFC 5246 here. see: https://www.rfc-editor.org/rfc/rfc5246#section-7)
While in the absence of widely used client certificates web services usually rely on establishing an encryted connection to first to authenticate users by some kind of challange response test like querying for username and password your client might want to either additionally secure access to his machines by additionally requiring a valid client certificate or even - probably not the best idea - replace a second authorization like the one already mentioned above.
Nevertheless all this are nothing but some ideas that I came along with given the riddle in your question.
Most probably the best idea might be to just ask your client what he/she meant when saying "... connecting from an https adress"
The quiz can't be viewed by any other users, unless the "Secure URL" is updated. But I can't figure out how to do that.
This simply means you must have an SSL certificate on the domain that hosts your canvas page. I would recommend rapidSSL.
Here is a general overview of what this entails: http://webnet77.com/SSL-certificates.html
Here is what we do:
get yourself host account with dedicated IP or better linux dedicated server
ask your host to generate Certificate Signing Request or do it yourself use openssl (don't know how to do it on windows)
get cheap ssl certificate (like rapidSSL) 9.90 per year or something just domain verification, google it.
send them your CSR
wait like 10 minutes
find your cert in your inbox attached
install it according to your server (Apache uses mod_ssl)
test it
Does anyone have an experience or just thoughts about securing MQ TCP
communication channels using stunnel?
I am integration with third party S.W which has MQ support built in but it can not support SSL. So to have some kind of security over the TCP we would like to use stunnel. Does any one have any thoughts how to implement and any best practices
I haven't used stunnel so I'll leave that part of the answer to another responder. With regard to WMQ, keep in mind that this will provide you with data privacy and data integrity over the stunnel link but will not give you channel-level services such as WMQ authentication. True, you will have some level of authentication on the stunnel connection itself, but anyone with a TCP route to the QMgr that does not arrive via stunnel will also be able to start that channel.
Your requirement for security obviously includes data privacy. If it also includes authentication and authorization, you might need to use something like BlockIP2 (from http://mrmq.dk )to filter incoming connections on that channel by IP address to insure they arrive over the stunnel link. Of course, there is nothing to prevent someone at the remote end from specifying any channel name to connect to so if you secure one channel, you need to secure them all - i.e. make sure that SYSTEM.DEF.* and SYSTEM.AUTO.* channels are disabled or that they use SSL and/or an exit to authenticate the inbound connection.
Finally, be aware that if WMQ is configured to accept the ID presented by the client then the connection has full administrative access and that includes remote code execution. To prevent this you must configure all inbound channels (RCVR, RQSTR, CLUSRCVR and SVRCONN) that are not administrative with a low-privileged ID in the channel's MCAUSER. For any channels that are intended for administrators, authenticate these with SSL. (Hopefully your 3rd party SW is an application and not an administrative tool! Any WMQ admin tool must support SSL or else don't use it!)
So by all means use stunnel to secure this link, just be sure to secure the rest of the QMgr or else anyone who can legitimately connect (or even anonymous remote users if you leave MCAUSER blank and aren't using SSL and/or exits) will just bypass the security or disable it.
There's a copy of the IMPACT presentation Hardening WMQ Security at https://t-rob.net/links/ which explains all this in more detail.
Rob - I agree with you. For that only we have MQIPT. Which is much better. For STunnel for MQ i have sloved the problem.
Keys -U need a .pem key (From Key manager you can create .p12 and use open ssl to covert to .PEM).
Client Side: Download and install stunnel have followoling entries in the config file
cert = XXX.pem
client = yes
[MQ]
accept = 1415
connect = DestinationIP:1415
Server Side:
cert = xxx.pem
client = no
[MQ]
accept = 1415
connect = MQIP:1415
Once you do this all you have do is just call the amquputc with the Queue name.